調べてみようコンテナセキュリティ その６ ～Harborつかってみた～

 前回はHarborの構築を行いました。

今回はHarborにログインしてイメージのプッシュを行いたいと思います。

まずはGUIからログインしてみましょう。

ちなみに、adminの初期パスワードは harbor.yml に記載があります。

ログインしてみると「library」というプロジェクトが1つだけある状態です。

「library」をクリックしてみると、当然ながら何もありません。

今回は、ここにイメージを追加する作業を行うのですがその前に1つやっておきたいことがあります。

今回は前回構築したHarbor用のサーバーからイメージのアップロードを行うのでこの作業を必要としませんが、他のマシンからイメージをアップロードしようとする場合に証明書が必要となりますのでその証明書をダウンロードできるリンクを用意します。

実は、設定してあるとこの画面に表示されるのです。

何をするかというと、Harborのサーバーに「/data/ca_download/」に証明書を置いてあげるのです。

証明書関係のファイルはいっぱいありますが、拡張子が ca.crt となっているものがそうなります。

前回構築した環境ですと、以下のコマンドで配置できます。

# cp /root/CA/ca.crt /data/ca_download/

ブラウザを更新すると「REGISTRY CERTIFICATE」というリンクが出てきます。

これで証明書をGUIからダウンロード可能になりました。

では続いて、一旦GUIからは離れコマンドラインでの操作となります。

docker login コマンドを使用して Harbor へログインします。

# docker login ＜harborのIPアドレスかFQDN＞ -u admin -p ＜パスワード＞

CUI のログインができたところで、GUI に戻ります。

先ほどの画面で、「PUSH COMMAND」というリンクがありますのでそちらをクリックします。

Harbor のリポジトリにpushを行うために、TAG を付ける命名規則と push の際のコマンドが表示されます。

これに従ってまずイメージの TAG 付けを行いましょう。

こちらは docker tag コマンドを使用します。

現在ローカルに保存してあるイメージは docker images で表示できるので好きなものを TAG 付けします。

ちなみにこの時、Harbor で使用されているイメージも確認できます。

ここでは CentOS 7 を利用します。

# docker tag centos:7 ＜HarborのIPアドレスかFQDN＞/library/centos:harbor-test

このコマンドは、元となるイメージを指定（centos:7）し、付与するTAGを指定された命名規則に従って＜HarborのIPアドレスかFQDN＞/＜転送するプロジェクト名＞/＜任意のイメージ名：任意のTAG名＞となっています。

それでは push します。

# docker push ＜harborのIPアドレスかFQDN＞/library/centos:harbor-test

ブラウザを更新すると、以下の様に push されたイメージが表示されます。

イメージを確認してみると、「Tags」に先ほどアップロードした tag 情報も確認することができます。

push ができたので pull してみましょう。

「Tags」のとなりに「Pull Command」がありますのでクリックしてコピーしてCUIで実行できますが、実行前にローカルに存在しているイメージを消しておいた方がわかりやすいと思います。

以下のコマンドで削除してみましょう

docker rmi ＜harborのIPアドレスかFQDN＞/library/centos:harbor-test

先ほどコピーしたコマンドを確認すると、@sha256:～～～～ と追加されている部分があると思います。

これはダイジェストというそのイメージに付与された普遍的な識別子です。

これを付けることで、確実にそのイメージをダウンロードすることができるという事ですね。

実際にやってみましょう。

docker pull ＜harborのIPアドレスかFQDN＞/library/centos@sha256:xxxxxx～～～～

ダイジェストを使ってダウンロードしてきたイメージは、tagが付与されていません。

そのため docker tag コマンドを使用して tag を付与することになりますが、イメージの指定にはイメージの名前ではなく「IMAGE ID」を使用します。

docker tag ＜IMAGE ID＞ ＜harborのIPアドレスかFQDN＞/library/centos:harbor-test

先ほどまで none だった tag が付与されたと思います。

これで、イメージを検査しプライベートなリポジトリを用意してそこへイメージを push し pull して使うことができるようになりました。

コンテナのセキュリティに関してはこれで一旦終わりとしたいと思います。

読んでくださった方々ありがとうございました。

次は、今まで作ったものを自動で構築とかしてみましょうかね。

以前書いたk8sの構築もdockerではできなくなりましたし、その辺も絡めたりとか。

もしくは、Tanzu製品があれよあれよとたくさん増えて何する製品なのかが分からなくなってきたので、それぞれどういう事を目的とした製品で何ができるのかをまとめた記事を書こうかと考えています。

調べてみようコンテナセキュリティ その５ ～harbor作ってみた～

前回までで、イメージの脆弱性や構成上の問題をチェックし対応することが可能になりました。

コンテナ用のイメージは普段DockerHubからpullしてくると思いますが、セキュリティ的な観点からプライベートなコンテナレジストリを用意したいと思うこともあると思います。

そこで、自分用のコンテナレジストリとしてharborの作成(今回)と使い方(次回)について記載したいと思います。

harborを何で作るかですが、いろんな作り方があるんですけど今回はdocker composeという複数のコンテナを管理するツールを使いたいと思います。

元になるOSは毎度おなじみCentos 7でやります。

それではやっていきましょう。

コンテナとして展開するのでdockerを使います。

まずはdockerの構築が必要ですが、ここではdockerの構築は省略させていただきdocker-composeの構築からやっていきたいと思います。

利用するdocker-composeとharborのバージョンは以下

 [バージョン]

  - docker-compose v2.5.1

  - harbor v2.5.1

まず、docker composeの導入です。

手順はこちら。

https://docs.docker.jp/compose/install.html#linux

・利用するv2.5.1を指定してコマンドを実行します。

　# curl -L https://github.com/docker/compose/releases/download/v2.5.1/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose

　# chmod +x /usr/local/bin/docker-compose

・バージョンの確認をします。

　# docker-compose version

　# Docker Compose version v2.5.1

docker composeはこれで準備完了です。

驚きの簡単さですね。

続いてharborになります。

こっちは、証明書の作成やそれに合わせたファイルの書き換えなどがあるので手順も多くしんどいです。

それゆえに、うまくいかないことも多いですので心を強く持って挑んでください。

まずはharborのバイナリをダウンロードしてきて、構築用のOSに転送します。

開発速度が速いので、今回記載しているバージョンより新しいものが出ているかと思いますが、その場合でもおそらく構築手順自体は同じだと思います。

今回は/root直下でやっています。

  - harborのバイナリダウンロード先

      - https://github.com/goharbor/harbor/releases

        使いたいバージョンの「Assets」からダウンロードできます。

・CentOS上で解凍します。今回は/root 直下

　# tar zxvf harbor-offline-installer-v2.5.1.tgz

証明書関連の作成に着手します。

これは正しく作成配置ができていないと、イメージを置いたりダウンロードしたりするときに認証が通らなくて失敗します。

個人的にはこれに一番苦労しました。

・作業用のディレクトリを作成し移動ます。

　# mkdir CA

　# cd CA

・CA証明書の秘密鍵を生成します。

　# openssl genrsa -out ca.key 4096

・CA証明書を生成 ※CNにharborホスト名をFQDNで入れます

　# openssl req -x509 -new -nodes -sha512 -days 3650 \

　 -subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=xxxx.xxxx" \

　 -key ca.key \

　 -out ca.crt

・秘密鍵を生成します。

　# openssl genrsa -out myharbor.key 4096

・証明書署名要求（CSR）を生成します。

　# openssl req -sha512 -new \

　    -subj "/C=CN/ST=Beijing/L=Beijing/O=example/OU=Personal/CN=xxxx.xxxx" \

  　  -key myharbor.key \

    　-out myharbor.csr

・x509v3拡張ファイルを生成します。

　# cat > v3.ext <<-EOF

　authorityKeyIdentifier=keyid,issuer

　basicConstraints=CA:FALSE

　keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment

　extendedKeyUsage = serverAuth

　subjectAltName = @alt_names

　[alt_names]

　IP.1=OSのIPアドレスを入力

　DNS.1=harborホストのFQDNを入力

　DNS.2=harborホストのショートネームを入力

　EOF

・このファイルを使用してv3.ext、harborホストの証明書を生成します。

　# openssl x509 -req -sha512 -days 3650 \

　    -extfile v3.ext \

  　  -CA ca.crt -CAkey ca.key -CAcreateserial \

    　-in myharbor.csr \

    　-out myharbor.crt

・ホストにサーバー証明書と秘密鍵を置きます。

　# mkdir -p /data/cert/

　# cp myharbor.crt /data/cert/

　# cp myharbor.key /data/cert/

・サーバー証明書、秘密鍵、CAファイルをharborホストのDocker証明書フォルダーにコピーします。

　# mkdir -p /etc/docker/certs.d/harborホストのFQDN/

　# cp myharbor.key /etc/docker/certs.d/harborホストのFQDN/

　# cp ca.crt /etc/docker/certs.d/harborホストのFQDN/

・harborの設定ファイルharbor.ymlに必要な情報を記入します。

　テンプレート(harbor.yml.tmpl)があるのでコピーして.ymlにします。

　# cd ../harbor

　# cp harbor.yml.tmpl harbor.yml

　# vi harbor.yml

　編集個所は以下

　# Configuration file of Harbor

　# The IP address or hostname to access admin UI and registry service.

　# DO NOT use localhost or 127.0.0.1, because Harbor needs to be accessed by external clients.

　hostname: reg.mydomain.com ※harborホストのFQDNに変更

　# http related config

　http:

　  # port for http, default is 80. If https enabled, this port will redirect to https port

　  port: 80

　

　# https related config

　https:

　  # https port for harbor, default is 443

　  port: 443

 　 # The path of cert and key files for nginx

　  certificate: /your/certificate/path ※/data/cert/myharbor.crt に変更

　  private_key: /your/private/key/path ※/data/cert/myharbor.key に変更

・インストールのスクリプトを実行します

　# ./prepare

　# ./install.sh

・ブラウザから以下へ接続を確認します。

　http://harborホストのIPアドレス

　

これで構築は完了です。

作業が多く何を作ってるのか見失いがちになりますが、ゆっくり一つ一つやっていきましょう。

初めて作るときはチェックシートなんかを用意してみてもいいかもしれませんね。

次回は、出来上がったharborへログインしてイメージのpushやpullを実行してみましょう。

調べてみようコンテナセキュリティ その４ ～dockle 使ってみた～

 今回は、dockleについてインストールして実際に使ってみたいと思います。

使ってるのはCentOS 7 なので、インストール方法はこちら。

  VERSION=$(

   curl --silent "https://api.github.com/repos/goodwithtech/dockle/releases/latest" | \

   grep '"tag_name":' | \

   sed -E 's/.*"v([^"]+)".*/\1/' \

  ) && rpm -ivh https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.rpm

公式(https://github.com/goodwithtech/dockle#installation)にこれだけしか書いてないんですが、これで動くのだろうか・・・

あ、いや、動くんだとは思いますよ、OSにあったバージョンのrpmを持ってきてインストールする内容だと思いますし。

むかしは、何もわからず「こうやったら動くって書いてあるからこうやればいい」と思ってやっていましたが、いまは「こういうことをするんだろうなこのコマンドで」とある程度はわかるようになってきたので、長い年月続ける意味ってあるんだなぁって・・・

では、やっていきましょう

実行すると以下のような出力が出てインストールが実行されます。

  https://github.com/goodwithtech/dockle/releases/download/v0.4.5/dockle_0.4.5_Linux-64bit.rpm を取得中

  準備しています...              ################################# [100%]

  更新中 / インストール中...

     1:dockle-0:0.4.5-1                 ################################# [100%]

動くものですね、結構マニュアルとかで「こうやったら動くよ」って書いてあってもそのままやったら動かないことも多く経験してきたものでいまだに動くと驚いちゃうんですよねぇ。

たいてい、「いや～、この製品使うならこういうことはやっておくのが常識でしょう？？？」みたいな、前提条件が省かれて手順が書かれてるようなことが多くて、この手順を成功させるために前もって必要なものがあったりしないかな？

という事を考えたり調べたりしちゃう書いてあることが信用できない悲しいSEなのです。

インストールできたので脆弱性のチェックをやっていきます。

  2022-07-22T17:09:32.027+0900    INFO    Failed to check latest version. not found version patterns

  WARN    - CIS-DI-0001: Create a user for the container

          * Last user should not be root

  INFO    - CIS-DI-0005: Enable Content trust for Docker

          * export DOCKER_CONTENT_TRUST=1 before docker pull/build

  INFO    - CIS-DI-0006: Add HEALTHCHECK instruction to the container image

          * not found HEALTHCHECK statement

  INFO    - CIS-DI-0008: Confirm safety of setuid/setgid files

          * setuid file: urwxr-xr-x usr/sbin/pam_timestamp_check

          * setuid file: urwxr-xr-x usr/bin/newgrp

          * setuid file: urwxr-xr-x usr/sbin/unix_chkpwd

          * setuid file: urwxr-xr-x usr/bin/passwd

          * setuid file: urwxr-x--- usr/libexec/dbus-1/dbus-daemon-launch-helper

          * setuid file: urwx--x--x usr/bin/chfn

          * setgid file: grwxr-xr-x usr/bin/write

          * setuid file: urwxr-xr-x usr/bin/su

          * setuid file: urwxr-xr-x usr/bin/gpasswd

          * setuid file: urwx--x--x usr/bin/chsh

          * setuid file: urwxr-xr-x usr/bin/mount

          * setuid file: urwxr-xr-x usr/bin/umount

          * setuid file: urwxr-xr-x usr/bin/chage

          * setgid file: grwx--x--x usr/libexec/utempter/utempter

  INFO    - DKL-LI-0003: Only put necessary files

          * Suspicious directory : tmp

このチェックでの判定は5段階のようです

『Level』

  https://github.com/goodwithtech/dockle#level

いろいろ出てきましたが、trivyの時ほどいっぱい怒られませんでしたね。

どういうところで引っかかったのかは以下で確認できます。

 『Checkpoint Summary』

 　https://github.com/goodwithtech/dockle#checkpoint-summary

どうやって改善したらいいのかも見ることができます。

これを参考に対処してねという事なのでしょう。

 『Checkpoint Details』

   https://github.com/goodwithtech/dockle/blob/master/CHECKPOINT.md

ちょうど「WARN CIS-DI-0001」の出力がありましたので、そちらの対処を行ってみたいと思います。

今回は、イメージを作成する設計書のDockerfileと、Dockerfileの内容を読み込んでイメージを作成する docker build コマンドを使用し、修正を組み込んだイメージcentos:dockle の作成をします。

Dockerfile の中身は以下の様になります。

  ＝＝＝＝

  # STEP1 CentOS 7 のイメージをベースにする

  FROM centos:centos7

  # STEP2 CIS-DI-0001の対処 

  RUN useradd -d /home/dockle -m -s /bin/bash dockle

  USER dockle

  ＝＝＝＝

ではイメージを作成してみます。

  # docker build -t centos:dockle dockle/

  Sending build context to Docker daemon  2.048kB

  Step 1/3 : FROM centos:centos7

   ---> eeb6ee3f44bd

  Step 2/3 : RUN useradd -d /home/dockle -m -s /bin/bash dockle

   ---> Running in 48139360d8c8

  Removing intermediate container 48139360d8c8

   ---> 4cf2480c9454

  Step 3/3 : USER dockle

   ---> Running in 950fa59666e5

  Removing intermediate container 950fa59666e5

   ---> d5cb3dc4dd14

  Successfully built d5cb3dc4dd14

  Successfully tagged centos:dockle

出来上がったイメージがちゃんと存在するか確認します。

  # docker images

  REPOSITORY   TAG       IMAGE ID       CREATED          SIZE

  centos       dockle    d5cb3dc4dd14   16 seconds ago   204MB

では、修正を盛り込んだイメージのチェックをしてみます。

  # dockle centos:dockle

  2022-07-25T10:18:17.309+0900    INFO    Failed to check latest version. not found version patterns

  2022-07-25T10:18:19.255+0900    FATAL   unable to initialize a image struct: failed to initialize source: reading manifest dockle in docker.io/library/centos: manifest unknown: manifest unknown

エラーとなってしまいました。

メッセージを検索等してみたところ、どうやらローカルにあるイメージをスキャンしたいんだけど実際はリモート(docker hubかな？)にスキャン対象イメージを探しに行ってしまっているということみたいです。

その対処は以下にありました。

  『Use Docker』

    https://github.com/goodwithtech/dockle#use-docker

dockleのコンテナを起動してスキャンしてもらって、結果が出たらdockleのコンテナは削除するという使い方のようですね。

ここに「You only need -v /var/run/docker.sock:/var/run/docker.sock when you'd like to scan the image on your host machine.」と記載があり、ローカルにあるイメージををスキャンするときはこうする必要があるみたいです。

では、コマンドを今回の環境に合わせて、バージョンとイメージを指定したいと思います。

バージョンの確認

  # dockle -v

  dockle version 0.4.5

コマンドはこうなりました。

  # docker run \

      --rm \

      -v /var/run/docker.sock:/var/run/docker.sock \

      -v $(pwd)/.dockleignore:/.dockleignore \

      goodwithtech/dockle:v0.4.5 \

      centos:dockle

実行してみたいと思います。

  Unable to find image 'goodwithtech/dockle:v0.4.5' locally

  v0.4.5: Pulling from goodwithtech/dockle

  97518928ae5f: Pull complete

  fc586ee9e6b2: Pull complete

  Digest: sha256:ebd36f6c92ac850408c7cbbf1eddf97e53565da9d661c5fb8ec184ad82a5358d

  Status: Downloaded newer image for goodwithtech/dockle:v0.4.5

  2022-07-25T01:41:20.053Z        INFO    Failed to check latest version. not found version patterns

  INFO    - CIS-DI-0005: Enable Content trust for Docker

          * export DOCKER_CONTENT_TRUST=1 before docker pull/build

  INFO    - CIS-DI-0006: Add HEALTHCHECK instruction to the container image

          * not found HEALTHCHECK statement

  INFO    - CIS-DI-0008: Confirm safety of setuid/setgid files

          * setuid file: urwxr-xr-x usr/bin/chage

          * setuid file: urwxr-xr-x usr/bin/passwd

          * setuid file: urwxr-xr-x usr/bin/su

          * setuid file: urwxr-xr-x usr/sbin/unix_chkpwd

          * setuid file: urwxr-xr-x usr/bin/umount

          * setuid file: urwx--x--x usr/bin/chfn

          * setuid file: urwxr-xr-x usr/bin/gpasswd

          * setuid file: urwxr-xr-x usr/sbin/pam_timestamp_check

          * setuid file: urwx--x--x usr/bin/chsh

          * setuid file: urwxr-xr-x usr/bin/newgrp

          * setgid file: grwxr-xr-x usr/bin/write

          * setuid file: urwxr-x--- usr/libexec/dbus-1/dbus-daemon-launch-helper

          * setgid file: grwx--x--x usr/libexec/utempter/utempter

          * setuid file: urwxr-xr-x usr/bin/mount

  INFO    - DKL-LI-0003: Only put necessary files

          * Suspicious directory : tmp

修正を盛り込んだことで「WARN CIS-DI-0001」の出力がなくなりました。

trivyとdockleを組み合わせて、より強固で安全なイメージの作成ができそうですね。

次回は、せっかく作ったイメージを置いておくコンテナレジストリを自分で作って使ってみるという事をやりたいと思います。

調べてみようコンテナセキュリティ その３ ～trivy使ってみた～

今回はコンテナイメージの脆弱性を確認してくれるtrivy編となります。

実際にインストールをしてみましょう。

まずはtrivy をyum でインストールするための作業です。

1．使ってるOSのバージョンを変数に入れます。

# RELEASE_VERSION=$(grep -Po '(?<=VERSION_ID=")[0-9]' /etc/os-release) 

2．1．の値を使ってyumのレポジトリを追加します。

# cat << EOF | sudo tee -a /etc/yum.repos.d/trivy.repo
[trivy]
name=Trivy repository
baseurl=https://aquasecurity.github.io/trivy-repo/rpm/releases/$RELEASE_VERSION/\$basearch/
gpgcheck=0
enabled=1
EOF

3．一旦全体のUpdateをおこないます。
# sudo yum -y update

4．trivyをインストールします。
# sudo yum -y install trivy

これでインストールできたようです。

コマンドを打ってみましょう・・・のまえに、スキャンするイメージが必要なので適用にCentos7でもイメージを引っ張っておきましょう。

# docker pull centos:centos7

それでは、trivyによるコンテナイメージのスキャンを実施です。

# trivy i centos:centos7

実行結果がかなり長く全部乗せられませんので見づらいかもしれないですがスクショを・・・

思ってたよりは全然きれいにテーブル表示形式で出力が見れました。

一番左が対象となるもので、そこからCVEの何に該当しているか、脆弱性の深刻さ、インストールされているバージョン、問題が解決しているバージョン、一番右はCVEのタイトルですかね。

で、これってどうやって対処するんでしょうと思ったあなた。

私も当然思いました。

仮になんですが、このイメージから展開したコンテナにログインしてyum update でもすればいいんでしょうか？（権限的にできる？

ま、とりあえずやってみましょ。

コンテナを起動します。

# docker run -d -i -t centos:centos7 /bin/bash

コンテナにログインするため、CONTAINER IDを確認します。
# docker ps
CONTAINER ID   IMAGE                                COMMAND                  CREATED         STATUS                             PORTS                       NAMES
8c70ec6e46e2   centos:centos7                       "/bin/bash"              6 minutes ago   Up 6 minutes                                                   eager_mclean

コンテナにログインしてyum update を実行します。

# docker exec -i -t 8c70ec6e46e2 /bin/bash

# yum update -y

先ほど「HIGH」で表示されていた「bind-license」もUpdateされていることが確認できました。
# cat /var/log/yum.log | grep bind
Nov 13 01:55:50 Erased: 32:bind-utils-9.11.4-26.P2.el7.x86_64
Nov 13 01:55:51 Erased: 32:bind-libs-9.11.4-26.P2.el7.x86_64
Nov 13 01:55:51 Erased: 32:bind-libs-lite-9.11.4-26.P2.el7.x86_64
Jun 09 01:36:23 Updated: 32:bind-license-9.11.4-26.P2.el7_9.9.noarch

yum update -y できたので、一旦exit でコンテナから抜けます。

この状態でイメージスキャンをしても、変更が保存されていないイメージしかいないため結果は変わりません。

そのため、docker commit で更新したコンテナから新しくイメージを「centos:update」として作成します。
# docker commit 8c70ec6e46e2 centos:update
sha256:6bc0f6964c196dc38a3b00bcf79a9b586306253808b08e8e26b16c80290831fc

作成されたものを確認してみると、SIZEが増えているのでちゃんとyum update の内容が反映されてそうですね。
# docker images
REPOSITORY                      TAG       IMAGE ID       CREATED              SIZE
centos                          update    6bc0f6964c19   About a minute ago   510MB
centos                          centos7   eeb6ee3f44bd   8 months ago         204MB

では改めて作成したイメージをスキャンしてみましょう。
# trivy i centos:update

Fixed Version があったものが全部表示されなくなったようですね。

アップデートで解消できる問題については、trivyで発見と対応後の状態を確認できることは確認できました。

ちょっと長くなってしまったので、dockleは次回に回したいと思います。

調べてみようコンテナやPodのセキュリティ その２ ～コンテナイメージの脆弱性確認ツールについて～

 コンテナイメージの脆弱性確認ツールについて

こちらは、コンテナのセキュリティに関して勉強していくシリーズの第2回となっています。

今回は、コンテナイメージの脆弱性確認ツールについて調べたことを書いていこうと思います。

コンテナイメージというものは、実はWindowsやCent OSのインストール時に使うisoとかと違って動かすアプリケーションに必要なファイルやディレクとりなどの階層が固められたものになります。

コンテナはホストOSのカーネルを利用するので、それ以外の部分で動かすアプリケーションに必要なものが固められたものがコンテナイメージというわけです。

なので、一般的なウイルス対策ソフトでファイルのスキャンをするというのとはちょっと内容が違ってきます。

一般的なウイルスソフトのスキャンは、スパイウェアやマルウェアの発見と駆除をしてくれます。

コンテナイメージでも同じようにファイルに問題がないか、変なプログラムがいないか、と言ったことをスキャンしてくれるのかというとそうではありません。

簡単に言いますと、イメージの中にあるアプリケーション等が既存の脆弱性(CVE)に該当していないかどうかという事を報告してくれます。

ここで覚えておいてほしいのが、脆弱性を報告してくれますがその対処は人間が行うという点です。

スパイウェアやマルウェアの駆除をしてくれる一般的なウイルスソフトは自動で駆除なり隔離なりをしてくれると思いますが、コンテナイメージの場合は人間が対処を行って大丈夫な状態のコンテナイメージを作成する必要があるという事ですね。

システム任せにできないのでかなり大変になりそうだなと思いました。

コンテナイメージのスキャンで有名なのが、Trivyという製品です。

先ほどの脆弱性に該当してないかどうかの確認と、設定ファイルの不備もチェックしてくれるようです。

こういったものが一般的に使われているようですね。

最初はTrivyを調べて記事にしようかと思ったんですが、これとはちょっと違うDockelというものもあるようでせっかくなら比較してみようかと思いました。

Dockelもコンテナイメージの脆弱性を確認してくれるツールなのですが、こちらはCIS Benchmark というシステムを安全に構築するためのベストプラクティスがありまして、そちらのコンテナに関係する部分についてもチェックを行ってくれるようです。

次回は実際にやってみた結果でブログを書きたいと思いますが、もしかしたらどちらか一方の記事になるかもしれません…

調べてみようコンテナやPodのセキュリティ

 今回から、Podやコンテナのセキュリティについて学習したことをまとめていきたいと思います。

なぜそんなことをしようと思ったのかといいますと、たまたまPodを実際に外部公開して使いましょう

となった場合、セキュリティの考え方は従来通りでいいんだろうか？

Podやコンテナにアンチウィルスソフトとかって入れるの？ それってどうなんだろ？

という事を考えて気になり始めたので、実際に調べてみたところだいぶ考え方が違うしやる事も違う

という事がわかったためです。

従来のWindows OSなどでは、パッチを適用したりアンチウィルスを入れてスキャンしたり、ファイアウォールで

防御したりという事がセキュリティ的な対応としてすぐに思いつく事ではないでしょうか。

しかし、コンテナやPodでは少々事情が異なります。

コンテナやPodというのは、使いたいOSやアプリのイメージを使用して構築します。

この時に、脆弱性のチェックを行って脆弱性の対応が済んでいる状態のイメージを使用することで脆弱性の対応を

完了してしまうのです。

時間がたてば、新しい脆弱性等が発見されたりしますので、その際は対応を行ったイメージを再度作成しそれを利用する。

こういった作業を繰り返すのがPodやコンテナにおける脆弱性への対応の一つとなります。

使うイメージの状態に問題がなければ大丈夫という考え方という事ですね。

外部からアクセスされて乗っ取られたらどうするかという部分については、コンテナやPod内で動くユーザーを、非root

権限のユーザーにするといった対応を行っていくことになります。

今後、このブログでは、イメージの脆弱性を確認するツール、イメージのマルウェアを確認するツール、外部リポジトリ

を使用した脆弱性対応などについて調べたり確認したことを書いていこうと思いますので、ご興味ありましたら読んでみてください。