Google Kubernetes Engineでアプリを動かしてみる

こんにちは、虎の穴ラボのM.Uです。

弊社が運用してるクリエイター支援プラットフォームである Fantia は Google Cloud Platform (以下,GCP)上で稼働しています。業務内では Google Compute Engine(以下,GCE)や Cloud Load Balancing などを利用していますが、今回はGCPの一つであるGoogle Kubernetes Engine(以下,GKE)を触ってみたので、その紹介をしてみたいと思います。

全体の流れ

  1. Kubernetesとは
  2. Node.jsで動く簡単なWebアプリを作成
  3. Docker image作成/ローカルで実行確認
  4. Google Cloud SDKの設定
  5. 作成した Docker imageをContainer Registryへpush
  6. GKEでアプリをデプロイする

1. Kubernetesとは

Kubernetesとは Dockerを使ってコンテナ化したアプリケーションのデプロイやスケーリングなどができるオープンソースのプラットフォームです。
複数サーバでのコンテナを管理する機能を持っていて、実際にコンテナが動作するノードとよばれるサーバーとノードのリソース使用状況を監視してコンテナを起動させるマスターサーバーがあります。その他にも、Dockerイメージを管理するレジストリサーバーも含まれます。
GKEは Kubernetes の機能をGCP内部で実現する仕組みです。例えば、ノードは実際にはGCEのインスタンスとして稼働しています。また Dockerのイメージファイルは Container Registryというサービスで push するようになっていますが、実際には Cloud Storage にバケットが作成されそこに保存されます。
Kubernetes の制御は kubectl コマンドが使えます。

今回はNode.jsで単純にテキストをブラウザに表示するアプリを作成したものをGKEでデプロイまで試します。

2. Node.jsで動く簡単なWebアプリを作成

Kubernetesは複数の Docker 環境をクラスタ化する仕組みです。まずは、Docker環境のWebサービスを動かすDockerイメージを用意する必要があります。
ネット上で一般公開しているNginxが入っている Dockerイメージを使ってもよいですが、せっかくなので簡単なアプリを実装してそれを Docker イメージにするところから初めてみましょう。
まずは、テキストを表示するだけの簡単なアプリを用意します。

main.js というファイルを作って"Google Kubernetes Engine"と表示させます。

var express = require('express');
var app = express();

var server = app.listen(8000, () => {
    console.log("Start express. port:" + server.address().port)
});

app.get('/', (req, res) => {
    res.send('Google Kubernetes Engine')
});


package.json ファイルの定義は以下のような具合で npmコマンドからモジュールのインストールが出来るようにします。 

{
    "name": "hello-server",
    "version": "1.0.0",
    "description": "",
    "main": "main.js",
    "scripts": {
        "start": "node main.js",
        "test": "echo \"Error: no test specified\" && exit 1"
    },
    "author": "m.u",
    "license": "MIT",
    "dependencies": {
        "express": "^4.16.3"
    }
}


次に Dockerのimageファイルを作成するための定義ファイルを作ります。ファイル名は Dockerfile です。

FROM node:8

ADD package.json /app/package.json
RUN cd /app && npm install
ADD main.js /app/

CMD cd /app && npm start

3. Docker image作成/ローカルで実行確認

 
作成した DockerfileからDockerイメージを作成します。カレントディレクトリに Dockerfile がある事を確認し、次のコマンドを実行します。
ここで気をつけることは Google Container Registryへpushするためにタグ付きで作成することです。

$ docker build -t ホスト名/プロジェクト名/イメージ名:タグ .

ホスト名:push先のリージョンに当たります。他にも gcr.io などがありますが、今回は asia.gcr.io にします。
プロジェクト名:今回利用しているGCPのプロジェクト名です。今回動かすプロジェクト名は mu-sample です。
イメージ名タグ名は任意で命名できます。今回は hello-server:v1 とします。

$ docker build -t asia.gcr.io/mu-sample/hello-server:v1 .

Dockerイメージが出来ました。まずはローカルで動作できるか確認してみましょう。

$ docker run -p 8000:8000 -d hello-server:1.0

http://localhost:8000/でアクセスすると以下のように"Google Kubernetes Engine"と表示されることを確認します。

f:id:toranoana-lab:20181002194826p:plain

4. Google Cloud SDKの設定

Google Cloud SDKのコマンド gcloud を使用しますが、今回はSDKのインストール手順は割愛します。
以降の gcloudコマンドがどのアカウントで実行されるのかを設定します。

$ gcloud config set account アカウント名

※gcloud auth list で現在どのアカウントが設定されているのかが確認できます。

アカウント認証を行います。次のコマンドを実行するとブラウザが起動してログイン認証を求められます。
許可ボタンを押すとコンソール側ではログインに成功したメッセージが来ます。

$ gcloud auth login

gcloud configを使ってプロジェクトの設定を行います。

gcloud config set project mu-sample

先にGKEのデプロイを行うための kubectlコマンドをインストールしておきましょう。

gcloud components install kubectl

5. 作成した Docker imageをContainer Registryへpush

Docker認証ヘルパーについて

コンテナイメージをContainer Registryへpushする gcloud dockerコマンドが存在しましたが、こちらはDockerクライアントバージョンが1.13以前までとなるようです。
よって、gcloudコマンドではなくdockerコマンドで GCPへの認証を行う必要があります。
Authentication Methods  |  Container Registry  |  Google Cloud

Docker認証ヘルパー ツールをインストールします。

gcloud components install docker-credential-gcr

Container Registryが使えるように認証コマンドを実行します。

docker-credential-gcr configure-docker

次のコマンドでアクセストークンを取得し docker loginを実行させています。

gcloud auth print-access-token | docker login -u oauth2accesstoken --password-stdin https://asia.gcr.io

成功すると Login Succeeded と返ってきます。
これで Container Registryへ pushできるようになります。

Container Registryへpush

docker push asia.gcr.io/mu-sample/hello-server:v1

GCPコンソール画面から Container Registry 画面を見てみましょう。
Dockerイメージがリポジトリに新たに作成されていれば成功です。

f:id:toranoana-lab:20180930012941p:plain

6. GKEでアプリをデプロイする

Kubernetes クラスタの作成

以下のコマンドでGKEコマンドで操作するインスタンスを作成します。
最初の説明でもありましたとおり、Kubernetesはコンテナが動作するサーバーをノードと読んでいます。
以下のコマンドの --num-nodesパラメータでノード数を3つにしています。

gcloud container clusters create sample-cluster --num-nodes=3

また、このサーバーはGoogle Compute Engine(以下、GCE)のインスタンスです。
コンソールからGCEの画面へいくとVMインスタンスが3つ立ち上がっているのが確認できます。

アプリケーションのデプロイ

ついにデプロイです。 hello-server は任意の名前です。
GKEのワークロードの名前として管理されます。ポートの指定は今回のアプリは8000番を指定しているので
コンテナーでも公開するポートを同一にします。

kubectl run hello-server --image=asia.gcr.io/mu-sample/hello-server:v1 --port 8000

アプリを外部に公開する

一時的に外部から接続できるようにしてみましょう。

kubectl expose deployment hello-server --type=LoadBalancer --port 80 --target-port 8000

GCPコンソールのネットワークを見ると新たにロードバランサーが作成されています。
kubectl get service コマンドでクラスターの情報を取得することが出来ます。

$ kubectl get service
NAME           TYPE           CLUSTER-IP      EXTERNAL-IP      PORT(S)        AGE
hello-server   LoadBalancer   10.31.253.187   xxx.xxx.xxx.xxx   80:30680/TCP   57s

EXTERNAL-IP が外部向けのIPアドレスになります。
ブラウザでアクセスすると、ローカルで実行した時と同様「Google Kubernetes Engine」と表示されます。

サービスとクラスターの削除

このままだとインスタンスが起動したままなので、サービスの停止とクラスターの削除を行います。

$ kubectl delete service hello-server
$ gcloud container clusters delete sample-cluster

最後に

GKEがどのような操作を通してKubernetesのデプロイを実現しているのかを見ていきました。
今回はデプロイ作業のみに絞って Kubernetes の概要を割愛しています。
公式ドキュメントも充実していますので、Kubernetes をすぐに体験したいならば、GKEを使ってみてはいかがでしょうか。


10/30(火) に『とらのあな開発室』の採用説明会を秋葉原で開催します! Webエンジニアがメインの説明会となりますが、デザイナー、ディレクターもあわせて募集していますので、ぜひ気軽にご参加下さい!
yumenosora.connpass.com


虎の穴ではJavascriptエンジニアをはじめとして一緒に働く仲間を絶賛募集中です!
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧下さい。
www.toranoana.jp

LINE BOT お天気通知くん

皆さんこんにちは、虎の穴ラボのO.Sです。

近頃は秋雨が多く、傘が必要な日が続いておりますね・・・
さて、皆さんはお出かけの際に傘を持っていくかどうか、どう判断しておりますか?

  • 天気予報を見る
  • 窓から差し込む朝日の強弱から判断する

などでしょうか・・・
天気予報を見る方は、朝バタバタしていると天気予報の確認を忘れてしまうことはありませんか?
そこで、天気予報と降水確率を取得し、傘を持っていくかどうかを通知してくれるLINE BOTを作成しました!!
ぜひ、いままで勘に頼っていた方もお天気通知BOTを作成して、雨の日に備えて下さい!

LINE BOTは以下の情報を通知します。

■ 出力情報

天気予報:対象地域
気温:最高気温/最低気温
傘予報:当日の6:00~12:00、12:00~18:00、18:00~24:00における降水確率により変動

降水確率対応表

降水確率 表示
30%未満 傘は持たなくても良いね!
30%が最高 折りたたみ傘があると安心!
40%以上 傘を持って行ったほうが良いね!

以下にLineBotの作成手順を記載しましたので、お役に立てると幸いです! 

■環境

続きを読む

AWS CloudFront API を使ったキャッシュ削除ツール

こんにちは、虎の穴ラボのS.Sです。

季節の変わり目でもあり、最近は朝晩が少し肌寒くなりましたね。

さて弊社の通販サイトでは、画像のキャッシュサーバーにAWS CloudFrontを利用していますが、
キャッシュしている画像をリンクはそのままに、今すぐに新しい画像に差し替えたい場合、
マネジメントコンソールにアクセスして、古い画像のキャッシュを削除する必要があります。
(デフォルト設定では、キャッシュが保持される期間は、24時間になっているため)

でも、非エンジニアがマネジメントコンソールにアクセスするのはハードル高いですよね。
そこで今回は、CloudFrontのAPI を使って、ブラウザ上で簡単にキャッシュの削除ができるツールをつくりました!

CloudFront API のSDKは [.NET、C++、Go、Java、JavaScript、PHP、Python]が用意されていますが、
この中でも今回は、社内ツールとして使うため、簡単に実装できるJavaScriptのSDKを選択しました。

◼️ API 接続に必要なアクセスキーを取得する
アクセスキーIDと シークレットアクセスキー をマネジメントコンソールにて作成します。
詳しくは、下記を参考にしてください。
docs.aws.amazon.com

◼️ CloudFront API に接続してみる
HTML上にて、SDKをインポートさせます。

<script src="https://sdk.amazonaws.com/js/aws-sdk-2.316.0.min.js"></script>

(※2018/9/18 時点での最新バージョン)

javascript にて、接続情報を設定します。

    var config = new AWS.Config({
        accessKeyId : xxxxxxxxxxxxx, //アクセスキーID
        secretAccessKey : xxxxxxxxxxxxx, //シークレットアクセスキー
        region : xxxxxxxxxxxxx  //リージョン
    });
    cloudfront = new AWS.CloudFront(config)

(※ 今回はサンプルなので、シークレットアクセスキーなど接続情報を直接書いていますが、くれぐれもマネはしないでくださいね)

これで一度実行してみて、エラーが発生しなければ、接続成功です!

◼️ 実際にCloudFront API で、キャッシュの削除処理をやってみる

・createInvalidation.js

$(".js-createInvalidationBtn").on('click', function() {
  //キャッシュを削除したいオブジェクトパスを格納
  var invalidationPath = $("#createInvalidationText").val();
  var invalidationPathList = invalidationPath.split(/\n/);

  var params = {
      DistributionId: xxxxxxx, //ディストリビューションの ID (CloudFrontのマネジメントコンソールにて確認)
      InvalidationBatch: {
         CallerReference: xxxxxxxx, //任意のユニークなID(timestampで可)
         Paths: {
           Quantity: invalidationPathList.length,
           Items: invalidationPathList
        }
     }
  };

  cloudfront.createInvalidation(params, function(err, data) {
      if (err){
         console.log(err, err.stack); // エラー発生時
      }
      else{
         console.log(data); // 成功(削除IDなどが返却される)
      }
  });
});

・createInvalidation.html (入力画面)

<script src="https://ajax.googleapis.com/ajax/libs/jquery/3.2.1/jquery.min.js"></script>
<script src="https://sdk.amazonaws.com/js/aws-sdk-2.316.0.min.js"></script>
<script src="/js/cdn/createInvalidation.js"></script>
<textarea id="createInvalidationText" rows="10" cols="50" placeholder="キャッシュを削除したい画像パスを入力して下さい"></textarea>
<input type="button" class="js-createInvalidationBtn" value="削除"/>

これでテキストボックスから削除したいオブジェクトパスを入力し、
「削除」ボタンを押せば、キャッシュ削除処理が実行されます。

◼️実行サンプル
・入力画面
f:id:toranoana-lab:20180919123257p:plain
・API実行時のレスポンス
f:id:toranoana-lab:20180919123303p:plain

これにより、わざわざマネジメントコンソールにログインしなくても、
ツールからキャッシュの削除が簡単に出来るようになりました!

※CloudFront API のリファレンスは下記にて公開されています。
これ以外にも様々な機能がありますので、ぜひご参考下さい。
https://docs.aws.amazon.com/cloudfront/index.html#lang/ja_jp



虎の穴ではJavascriptエンジニアをはじめとして一緒に働く仲間を絶賛募集中です!
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧下さい。
www.toranoana.jp

また虎の穴は、技術書典5にスポンサー出展します!
新刊もありますので、ぜひブース番号「ス08」へお越しください。
techbookfest.org

とらのあな開発室ご用達の開発ツール紹介

こんにちは! とらのあな開発室です。

とらのあな開発室では、エディタやIDEなどの開発ツールを統一してはおらず、 各人の好みに任せてあります。

そんな中、開発室の中で人気のツールはどれなのか、実は便利なツールが他にあるのではないかと考え、今回の記事を書かせてもらいました。

続きを読む

vulsの導入・slackの日次通知

みなさんこんにちは、虎の穴ラボです。

今回は、各サービスのサーバにインストールされているパッケージのセキュリティチェックとslack通知の導入を行います。

導入の経緯

弊社のサービスは、KEEPER、とらのあなクラフトなど様々なサービスごとに複数台のサーバがあり
AWS、GCP、ConoHaなど多様なインフラプラットフォームを使用しています。

それ故、手動でセキュリティチェックを行うと管理コストが高くなってしまいます。
そこで、vulsで毎日セキュリティを行い、slackに通知するようにしました。


vulsの構築の方法は
↓のページを参考にしました。
https://blog.dshimizu.jp/article/810

パッケージインストール

yum install apt install ca-certificates git openssh-server sqlite build-essential wget curl

ユーザ作成

groupadd -g 20001 vuls
useradd -u 20001 -g vuls -G sudo -d /home/vuls -m vuls -s /bin/bash
vim /etc/sudoers.d/vuls

vuls ALL=NOPASSWD: ALL

sudo su - vuls

ssh鍵設定

mkdir .ssh
chmod 700 .ssh
ssh-keygen -t rsa -b 4096 -C "foo@example.com"
cat ~/.ssh/id_rsa.pub >> .ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

goのインストール

wget https://storage.googleapis.com/golang/go1.8.3.linux-amd64.tar.gz
sudo tar -C /usr/local -xzf go1.8.3.linux-amd64.tar.gz
vim .bashrc
export GOROOT=/usr/local/go
export GOPATH=$HOME/go
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
mkdir ~/go

以下のコマンド実行時にエラーが出なければgoのインストール完了

go version

ログ用のディレクトリ作成

sudo mkdir /var/log/vuls
sudo chown vuls:vuls /var/log/vuls
sudo chmod 700 /var/log/vuls

go-cve-dictionaryのインストール

mkdir -p $GOPATH/src/github.com/kotakanbe
cd $GOPATH/src/github.com/kotakanbe
git clone https://github.com/kotakanbe/go-cve-dictionary.git
cd go-cve-dictionary
make install
cd
for i in {2002..2017}; do go-cve-dictionary fetchnvd -years $i; done

goval-dictionaryのインストール

cd $GOPATH/src/github.com/kotakanbe
git clone https://github.com/kotakanbe/goval-dictionary.git
cd goval-dictionary
make install
cd
goval-dictionary fetch-redhat 7
goval-dictionary fetch-amazon

goval-dictionaryのオプションを変更するとredhat系(CentOS)やAmazon Linuxの他にUbuntuなどもセキュリティチェックできます
下のリンクにredhat系やAmazon Linux以外のOSをセキュリティチェックしたいときのやり方が載っています。
https://github.com/kotakanbe/goval-dictionary

vulsのインストール

mkdir -p $GOPATH/src/github.com/future-architect
cd $GOPATH/src/github.com/future-architect
git clone https://github.com/future-architect/vuls.git
cd vuls
make install


vulsのコンフィグファイルを設定します

cd
vim config.toml

コンフィグファイルには、対象のサーバを指定します。
今回、slack通知を行うため、slackの設定も入れています。

[default]
port = "22"

[slack]
hookURL      = "https://hooks.slack.com/services/YYYYYYYYY/XXXXXXXXX/ZZZZZZZZZZZZZZZ"
channel      = "#dev-infra"
authUser     = "vuls-test"

[servers.keeper-ap1]
host = "ec2-255-255-255-255.ap-northeast-1.compute.amazonaws.com"
user = "centos"
keyPath = "/home/vuls/key/KEEPER-AP1-KEY.pem"

[servers.keeper-ap2]
host = "ec2-255-255-255-254.ap-northeast-1.compute.amazonaws.com"
user = "centos"
keyPath = "/home/vuls/key/KEEPER-AP2-KEY.pem"

以下のコマンドで設定に問題ないかどうかがチェックできます。

vuls configtest

※対象のサーバが初接続の場合は失敗するので、1回ssh接続をしてからテストします。

問題なければ以下のコマンドを打ちます。

vuls scan -deep
vuls report -to-slack

slackに通知が来るので内容を確認します。
f:id:toranoana-lab:20180906195614p:plain




これで、vulsによるセキュリティチェックができるようになったので、
cronで定時実行します。↓参考サイト
https://blog.adachin.me/archives/5619

cronの設定

crontab -e
#vuls dictionary update
00 19 * * * sudo -u vuls /home/vuls/go/bin/go-cve-dictionary fetchnvd -last2y -dbpath=/home/vuls/cve.sqlite3
00 22 * * * sudo -u vuls /home/vuls/go/bin/go-cve-dictionary fetchjvn -latest -dbpath=/home/vuls/cve.sqlite3

#vuls scan/report
00 0 * * * sudo -u vuls /home/vuls/go/bin/vuls scan -deep -config=/home/vuls/config.toml -results-dir=/home/vuls/results -cachedb-path=/home/vuls/cache.db
20 0 * * * sudo -u vuls /home/vuls/go/bin/vuls report -cvedb-path=/home/vuls/cve.sqlite3 -ovaldb-path=/home/vuls/oval.sqlite3 -config=/home/vuls/config.toml -results-dir=/home/vuls/results -format-short-text -format-json -to-slack -lang=ja

#vuls results remove
00 18 * * * sudo find /home/vuls/results/ -mtime +30 -exec rm -f {} \;


これで、時間になれば通知が来ます。
f:id:toranoana-lab:20180906192526p:plain
※サーバの時刻ががUTCなので、cronの設定+9時間に来てます。



これで、毎日サーバにインストールされているパッケージの脆弱性をチェックできます。
また、3ヶ月程度セキュリティのセキュリティーアップデートをしなかっただけでこれだけの脆弱性の発見があるので
日々のチェックの重要性を感じました。


最後に、虎の穴ではRubyエンジニアをはじめとして一緒に働く仲間を絶賛募集中です。
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧下さい。
www.toranoana.jp

AWSから高額請求が来た話

こんにちは!虎の穴開発室N.Tです。
今回は自宅で勉強中に起きた事故についてご紹介します。

AWSからのメール

ある日AWSから[Your AWS account is Compromised]という表題メールが送られてきました。
私は英語が全くできませんが、自分のアカウントに何かが起きていることは読み取れるので、
気になって表題を翻訳して見ると「あなたのAWSアカウントが侵害されている」と出たため、
びっくりしてAWSコンソールにログインしてみました。

被害状況

幸いなことにAWSコンソールにはログインできました。以下、主な被害状況です。

  • 請求額は約$600以上。
  • EC2の請求金額だけが異常に高額。
  • 全てのリージョンから料金発生。
  • 各リージョンで作成した覚えのないインスタンスが大量に稼働。

原因

そもそもなぜアカウントが侵害されてしまったのかというと
数日前、練習のためRailsで画像ファイルのアップロード処理を実装する際、
Amazon S3との接続のためソースコードにアクセスキーとシークレットキーを直接記載し、
そのままコミットしてしまいました。 玄人から見ればそんなバカなことするわけないと思いますが、
素人の私はアクセスキーがネットに流出することの恐ろしさを認識していませんでした。
また、自分が勉強用に作ったリポジトリにアクセスするような暇人はいないとも思っていたのです。
しかし、悪意のあるBOTがGitHubをクローリングしており、 私のようにミスを犯す人を狙っていたのです。
これは後で調べたことですが、AWSも同様にクローリングを行なっており、
誤ってアクセスキーをコミットするとAWSから通知が来ることもあるそうです。

対応

AWSから送られて来たメールに対応すべきことが記載されていました。
以下、日本語で要約したものです。

  1. rootアカウントのパスワードを更新する。
  2. AWSアクセスキーをローテーションし削除する。
  3. すべてのリージョンで不正利用のためのアカウントを確認する。(被害にあったインスタンスはメールに記載されています。)
  4. IAMユーザー、AMI、EBSボリューム、スナップショットで自分が認識していないものを全て削除する。
  5. 不正なリソースを全て終了させる。
  6. 上記を行なった上で5日以内にAWSに返答*1する。

アカウントの復活作業をユーザー側で対応していることが確認されたら、
AWS側で審査の上、認められれば正しい請求額に修正してくださいます。

ベストプラクティス

今回のようなことが2度と起きないようにするためにもアクセスキーの正しい管理を知る必要があります。 AWS公式がアクセスキーの管理についてのベストプラクティスを提供しています。

docs.aws.amazon.com

再発防止策

AWSから対応完了の連絡がくるとともに、予期せぬ請求にそなえていくつか解決策をご教示いただきました。

docs.aws.amazon.com

docs.aws.amazon.com

docs.aws.amazon.com

これらのサービスについては今後当ブログで詳細を解説できればと思います。

エンジニア大募集!!

虎の穴ではエンジニアを大募集中です!!
JavaやRubyでの開発やAWSやGCPに興味のある方、ぜひご応募ください!

www.toranoana.jp

*1:AWSとのやりとりはAWSコンソールのサポートセンターで行います。
私は間違えて、最初メールでやりとりをしてしまいましたが、
AWSカスタマーセンターから日本人の担当者の方から日本語でメッセージが届き、
改めて海外拠点と料金の調整についてやりとりするように言われました。
とても丁寧で素晴らしい対応でした。

Brakemanを使用した各サービスの定時セキュリティチェック

みなさんこんにちは、虎の穴ラボです。

今回は、Ruby on Railsのソース上のセキュリティチェックを行うBrakemanの導入と定時セキュリティチェックを行います。

導入の経緯

弊社のサービスは、KEEPERなどの様々なサービスがあります。
ただ、各サービスのセキュリティチェックを手動で行うには、管理コストがかかります。
そこで、セキュリティの向上と管理コストの軽減を削減したいと思い、Brakemanの導入を決定しました。

Gitからソースを取得する

Gitからソースを取得するときに、認証方法はいろいろありますが、
コミット権限のないDeploy鍵を使用してプログラムソースを取得していきます。

 
ただ、Deploy鍵は鍵1つに対してリポジトリ1つが必要となり、複数のセキュリティチェックを行いたい場合は、
以下のように、リポジトリの数だけの鍵生成と、鍵とリポジトリを関連付けを行います。

鍵作成

リポジトリごとに鍵を生成していきます。

ssh-keygen -f ~/.ssh/keeper
・・・・

 

鍵とリポジトリの関連付け

生成した鍵と、リポジトリの関連付けを行っていきます。

vi ~/.ssh/config

 

Host github-keeper
  User git
  Port 22
  HostName github.com
  IdentityFile ~/.ssh/keeper
  TCPKeepAlive yes
  IdentitiesOnly yes

・・・・・


作成した鍵をgithubのリポジトリのDelpoy Keyに登録します。
f:id:toranoana-lab:20180831114839p:plain
これで、鍵認証でgit cloneが利用可能になるので、ソースを落とします。

mkdir ~/project
cd ~/project
git clone git@github-keeper:toratora/keeper.git
・・・

brakemanの導入

以下のコマンドでbrakemanをインストール

gem install brakeman


↓のコマンドを実行すると、セキュリティチェックができます。

brakeman -A ~/project/keeper/

 

チェックの自動化

毎回チェックコマンドを打つ手間なので、cronで日次でチェックするようにしました。
また、brakemanはhtml出力ができるので、ブラウザ上から結果を確認できるようにします。


gitで最新のソースを取得しつつ、チェック処理をシェルに書います。

vi ~/brakeman.sh

 

#!/bin/bash
cd /root/project/keeper/ && git checkout .  && git pull
・・・・・・

/root/.rbenv/shims/brakeman -a /root/project/keeper -o /var/www/brakeman/html/keeper.html
・・・・・・

cronに登録します。

crontab -e
0 0 * * * /bin/bash /root/brakeman.sh >>/root/log/brakeman.log 2>>/root/log/brakeman-err.log

 

実行結果をブラウザ上で確認するため、nginxの設定をします。

vi /etc/nginx/conf.d/default.conf
server {
    listen 80;
    server_name 127.0.0.1;

    location /brakeman/ {
       alias /var/www/brakeman/html/;
   ・・・・・
    }
}
・・・・・

nginxの設定反映

nginx -s reload

IPアドレス/brakeman/keeper.html
で、ブラウザから結果を見てみると

f:id:toranoana-lab:20180831121753p:plain

 
これで、ブラウザ上から、日次のセキュティチェックの結果が確認できます。
Security Warningsがあるので、・・・・修正しないといけませんね・・・・

これで、SQLインジェクションや、XSSなどのセキュリティ脆弱性の対策を
5分程度のWebページの閲覧だけでチェックできるようになり、
管理コストの低減とセキュリティの向上の両立ができました。


最後に、虎の穴ではRubyエンジニアをはじめとして一緒に働く仲間を絶賛募集中です。
この記事を読んで、興味を持っていただけた方はぜひ弊社の採用情報をご覧下さい。
www.toranoana.jp