セキュリティベビーベッド：Docker

Dockerコンテナーは、最も一般的なコンテナー化テクノロジーです。 当初は、主に開発環境とテスト環境で使用されていましたが、徐々に本番環境に移行しました。 雨の後のキノコのように、生産環境でDockerコンテナが増え始めましたが、この技術を使用する人のほとんどは、Dockerコンテナを安全に公開する方法について考えませんでした。



OWASPに基づいて、Dockerコンテナ上に構築された環境を大幅に保護するルールのリストを準備しました。

ルール0

ホストマシンとDockerには、現在のすべての更新が含まれている必要があります。

コンテナー環境からホストシステムへのエスケープにつながる既知の脆弱性（通常はホストシステムでの権限昇格につながる）から保護するには、ホストOS、Docker Engine、およびDocker Machineのすべてのパッチをインストールすることが非常に重要です。



さらに、コンテナは（仮想マシンとは異なり）カーネルをホストと共有するため、コンテナ内で実行されるカーネルエクスプロイトはホストカーネルで直接実行されます。 たとえば、十分に隔離されたコンテナ内で実行されるカーネル権限昇格の悪用（Dirty COWなど）は、ホスト上のルートアクセスにつながります。

ルール1

Dockerデーモンのソケットへのアクセスを許可しないでください

Dockerサービス（デーモン）は、着信API接続にUNIXソケット/var/run/docker.sockを使用します。 このリソースの所有者は、rootユーザーでなければなりません。 そして他の方法はありません。 このソケットへのアクセス権を変更することは、ホストシステムへのルートアクセスを許可することと本質的に同等です。



また、/ var / run / docker.sockソケットをコンテナーで操作しないでください。コンテナーを使用しない場合は、コンテナー内のサービスを侵害するとホストシステムを完全に制御できるためです。 このようなものを使用するコンテナがある場合：

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

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

またはdocker-composeの場合：

 volumes: - "/var/run/docker.sock:/var/run/docker.sock"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを早急に変更する必要があります。



そして最後に、特に追加の保護方法（少なくとも認証）を使用せずに、必要な絶対的な確実性がない限り、Docker TCPソケットを使用しないでください。 デフォルトでは、Docker TCPソケットは外部インターフェース0.0.0.0:2375（HTTPの場合は2376）でポートを開き、コンテナーを完全に制御し、潜在的にホストシステムを使用できるようにします。

ルール2

コンテナ内で非特権ユーザーを構成する

特権のないユーザーを使用するようにコンテナを構成することは、特権の昇格攻撃を回避するための最良の方法です。 これはさまざまな方法で実行できます。



1.「docker run」コマンドの「-u」オプションを使用します。

 docker run -u 4000 alpine
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2.イメージのビルド中：

 FROM alpine RUN groupadd -r myuser && useradd -r -g myuser myuser <      root-, ,  > USER myuser
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3. Dockerデーモンで「ユーザー名前空間」（ユーザー環境）のサポートを有効にします。

 --userns-remap=default
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

詳細については、 公式ドキュメントをご覧ください。



Kubernetesでは、後者はrunAsNonRootオプションを介してセキュリティコンテキストで構成されます。

 kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... runAsNonRoot: true ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール3

コンテナの機能を制限する

Linuxでは、カーネル2.2以降、 Linuxカーネル機能と呼ばれる特権プロセスの機能を制御する方法があります（詳細についてはリンクを参照してください）。



Dockerは、デフォルトでこれらのカーネル機能の事前定義されたセットを使用します。 そして、次のコマンドを使用してこのセットを変更できます。

 --cap-drop —     --cap-add —    
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最適なセキュリティ設定は、最初にすべての機能を無効にし（--cap-drop all）、次に必要な機能のみを接続することです。 たとえば、次のように：

 docker run --cap-drop all --cap-add CHOWN alpine
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして最も重要な（！）：–privilegedフラグを使用してコンテナーを実行しないでください!!!



Kubernetesでは、Linux Kernel Capabilities制約は、機能オプションを介してセキュリティコンテキストで構成されます。

 kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... capabilities: drop: - all add: - CHOWN ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール4

no-new-privilegesフラグを使用します

コンテナを起動するとき、コンテナ内での権限昇格を防ぐ--security-opt = no-new-privilegesフラグを使用すると便利です。



Kubernetesでは、Linux Kernel Capabilities制約は、allowPrivilegeEscalationオプションを介してセキュリティコンテキストで構成されます。

 kind: ... apiVersion: ... metadata: name: ... spec: ... containers: - name: ... image: .... securityContext: ... allowPrivilegeEscalation: false ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール5

コンテナー間通信をオフにする

デフォルトでは、コンテナ間通信はDockerで有効になっています。これは、すべてのコンテナが（docker0ネットワークを使用して）相互に通信できることを意味します。 この機能を無効にするには、–icc = falseフラグを指定してDockerサービスを実行します。

ルール6

Linuxセキュリティモジュールを使用する（Linuxセキュリティモジュール-seccomp、AppArmor、SELinux）

デフォルトでは、DockerはすでにLinuxセキュリティモジュールのプロファイルを使用しています。 したがって、 セキュリティプロファイルを無効にしないでください。 それらでできる最大のことは、ルールを強化することです。



seccompのデフォルトプロファイルは、 ここから入手できます 。



また、Dockerは保護のためにAppArmorを使用し、Docker Engine自体がコンテナーの起動時にAppArmorのデフォルトプロファイルを生成します。 つまり、次の代わりに：

 $ docker run --rm -it hello-world
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

起動します：

 $ docker run --rm -it --security-opt apparmor=docker-default hello-world
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ドキュメントには、nginxのAppArmorプロファイルの例も記載されていますが、これは非常に可能です（必要です！）。

 #include <tunables/global> profile docker-nginx flags=(attach_disconnected,mediate_deleted) { #include <abstractions/base> network inet tcp, network inet udp, network inet icmp, deny network raw, deny network packet, file, umount, deny /bin/** wl, deny /boot/** wl, deny /dev/** wl, deny /etc/** wl, deny /home/** wl, deny /lib/** wl, deny /lib64/** wl, deny /media/** wl, deny /mnt/** wl, deny /opt/** wl, deny /proc/** wl, deny /root/** wl, deny /sbin/** wl, deny /srv/** wl, deny /tmp/** wl, deny /sys/** wl, deny /usr/** wl, audit /** w, /var/run/nginx.pid w, /usr/sbin/nginx ix, deny /bin/dash mrwklx, deny /bin/sh mrwklx, deny /usr/bin/top mrwklx, capability chown, capability dac_override, capability setuid, capability setgid, capability net_bind_service, deny @{PROC}/* w, # deny write for all files directly in /proc (not in a subdir) # deny write to files not in /proc/<number>/** or /proc/sys/** deny @{PROC}/{[^1-9],[^1-9][^0-9],[^1-9s][^0-9y][^0-9s],[^1-9][^0-9][^0-9][^0-9]*}/** w, deny @{PROC}/sys/[^k]** w, # deny /proc/sys except /proc/sys/k* (effectively /proc/sys/kernel) deny @{PROC}/sys/kernel/{?,??,[^s][^h][^m]**} w, # deny everything except shm* in /proc/sys/kernel/ deny @{PROC}/sysrq-trigger rwklx, deny @{PROC}/mem rwklx, deny @{PROC}/kmem rwklx, deny @{PROC}/kcore rwklx, deny mount, deny /sys/[^f]*/** wklx, deny /sys/f[^s]*/** wklx, deny /sys/fs/[^c]*/** wklx, deny /sys/fs/c[^g]*/** wklx, deny /sys/fs/cg[^r]*/** wklx, deny /sys/firmware/** rwklx, deny /sys/kernel/security/** rwklx, }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール7

コンテナリソースを制限する

このルールは非常に単純です。次のDoS / DDoS攻撃中にコンテナがすべてのサーバーリソースを使い果たすのを防ぐために、各コンテナのメモリ使用制限を個別に設定できます。 制限できるのは、メモリの量、CPU、コンテナの再起動の回数です。



順番に行きましょう。



記憶



-mまたは--memoryオプション



コンテナが使用できるメモリの最大量。 最小値は4m（4メガバイト）です。



オプション--memory-swap



スワップを構成するオプション（スワップファイル）。 巧妙に設定：

• --memory-swap> 0の場合、-memoryフラグも設定する必要があります。 この場合、memory-swapは、スワップに加えてコンテナで使用可能な合計メモリ量を示します。
• より簡単な例。 --memory = "300m"、および--memory-swap = "1g"の場合、コンテナは300MBのメモリと700MBのスワップ（1g-300m）を使用できます。
• --memory-swap = 0の場合、設定は無視されます。
• --memory-swapが--memoryと同じ値に設定されている場合、コンテナにはスワップがありません。
• 値--memory-swapが設定されていないが、-memoryが設定されている場合、スワップの数は指定されたメモリの量の2倍に等しくなります。 たとえば、-memory = "300m"で、-memory-swapが設定されていない場合、コンテナは300MBのメモリと600MBのスワップを使用します。
• --memory-swap = -1の場合、コンテナはホストシステムで可能なすべてのスワップを使用します。

ホステスへの注意：コンテナ内で起動された無料のユーティリティは、コンテナで利用可能なスワップの実際の値ではなく、ホストスワップの数を表示します。



オプション--oom-kill-disable



OOM（メモリ不足）キラーを有効または無効にできます。



注意！ OOM Killerをオフにできるのは--memoryオプションが設定されている場合のみです。そうしないと、コンテナ内のメモリ不足により、カーネルがホストシステムプロセスの強制終了を開始する可能性があります。



--memory-swappiness、-memory-reservation、-kernel-memoryなどの他のメモリ管理設定オプションは、コンテナのパフォーマンスを調整するためのものです。



CPU



オプション--cpus



このオプションは、コンテナが使用できる使用可能なプロセッサリソースの量を設定します。 たとえば、2つのCPUを持つホストがあり、-cpus = "1.5"を設定した場合、コンテナは1.5プロセッサを使用することが保証されます。



オプション--cpuset-cpus



特定のコアまたはCPUの使用を構成します。 値は、ハイフンまたはコンマで指定できます。 最初のケースでは、許可されたコアの範囲が示され、2番目のケースでは特定のコアが示されます。



コンテナの再起動回数

 --restart=on-failure:<number_of_restarts>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この設定は、コンテナが予期せずクラッシュした場合にDockerがコンテナの再起動を試行する回数を設定します。 コンテナの状態が実行中に変更されると、カウンターはゼロにリセットされます。



稼働していないサービスの無限の再起動を回避するために、5などの小さな正の数を設定することをお勧めします。

ルール8

読み取り専用のファイルシステムとボリュームを使用する

コンテナがどこかに何かを書き込む必要がない場合は、可能な限り読み取り専用ファイルシステムを使用する必要があります。 これは、潜在的な侵入者の生活を大きく複雑にします。



読み取り専用ファイルシステムでコンテナを起動する例：

 docker run --read-only alpine
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

読み取り専用モードでボリュームを接続する例：

 docker run -v volume-name:/path/in/container:ro alpine
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ルール9

コンテナの安全性分析ツールを使用する

既知の脆弱性を持つコンテナを検出するには、ツールを使用する必要があります。 それらの多くはまだありませんが、それらは：



•無料：

• クレア。

•コマーシャル：

• Snyk （無料版があります）;
• anchore （無料版があります）;
• JFrog XRay ;
• Qualys 。

また、Kubernetesには、構成エラーを検出するためのツールがあります。

• kubeaudit ;
• kubesec.io ;
• キューブベンチ 。