[WLS, Kubernetes, Docker] Security Best Practices for WebLogic Server Running in Docker and Kubernetes

原文はこちら。
https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes

Overview

WebLogic Server（WLS）チームは、KubernetesおよびDockerクラウド環境でWLSを実行するための新しい統合機能に投資しています。この取り組みの一環として、WebLogic Server実行時にDockerおよびKubernetes環境を保護するためのベストプラクティスを割り出しました。
これらのベストプラクティスは、以下のドキュメントにある一般的なWebLogic Serverの推奨事項に追加されるものです。
Oracle® Fusion Middleware
Securing a Production Environment for Oracle WebLogic Server
12c (12.2.1.3.0)
https://docs.oracle.com/middleware/12213/wls/LOCKD/intro.htm

Ensuring the Security of WebLogic Server Running in Your Docker Environment

References to Docker Security Resources

以下の推奨事項は、列挙したような様々なソースのドキュメントおよびホワイトペーパーを基にしています。

Summary of Recommendations

本番環境を保護するにあたっての推奨事項は以下の通りです。
  1. CIS Dockerベンチマークを使用してDockerの設定を検証します。これは、サードパーティのツールを使用して手動または自動で行うことができます。
  2. 適切なCIS Operating Systemベンチマークを使用して、ホストOSの設定を検証します。
  3. CISベンチマークで未対応の追加のホストハードニングの推奨事項を評価します。
  4. CISベンチマークで未対応の追加のコンテナランタイムの推奨事項を評価します。
これらについては、以降のセクションで詳しく説明します。

Validate Your Docker Configuration Using the Center for Internet Security (CIS) Docker Benchmark

The Center for Internet Security (CIS) は、Docker Community Editionと複数のDocker EEバージョンのベンチマークを作成しており、最新のベンチマークはDocker EE 1.13用で、Docker EEの新バージョンがリリースされた後に新たなベンチマークが追加されています。これらのベンチマークにはDockerを安全に設定するための100個ほどの詳細な推奨事項が含まれています。この推奨事項は、ホストコンポーネントとDockerコンポーネントの両方に適用され、以下のトピックで構成されています。
  • Host configuration（ホストの構成）
  • Docker daemon configuration（Dockerデーモンの構成）
  • Docker daemon configuration files（Dockerデーモンの構成ファイル）
  • Container Images and Build File（コンテナイメージとビルドファイル）
  • Container Runtime（コンテナランタイム）
  • Docker Security Operations（Dockerセキュリティオペレーション）
  • Docker Swarm Configuration（Docker Swarmの構成）
詳細は以下のベンチマークのドキュメントをご覧ください。
CIS Docker Benchmarks
https://www.cisecurity.org/benchmark/docker/
CIS Dockerベンチマークの各推奨事項に対して、手動または自動ツールを使用して構成を検証する必要があります。Dockerの構成を検証できるCISパートナーのベンチマークツールのリストは以下のURLからご覧いただけます。
CIS Center for Internet Security
https://www.cisecurity.org/
ベンチマークツールには、次のものが含まれます（アルファベット順）。
注：CISベンチマークは、商用使用のためのライセンスが必要です。詳細については、以下のURLをご覧ください。
CIS SecureSuite Membership Terms of Use
https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/

Validate Your Host Operating System (OS) Using the CIS Benchmark

The Center for Internet Security (CIS) では、さまざまなLinuxディストリビューションやAIX、Solaris、Microsoft Windows、OSXなど、さまざまなOSのベンチマークも作成しています。
これらのベンチマークには、ホストOSを安全に設定するための一連の詳細な推奨事項が含まれています。たとえば、CIS Oracle Linux 7ベンチマークには、200を超える推奨事項と300ページ以上の指示が含まれています。この推奨事項は、Linux構成におけるすべての側面に適用されます。
詳細は、ベンチマーク文書をご覧ください。
CIS Benchmarks
https://www.cisecurity.org/cis-benchmarks/
手動または自動ツールを使用して、適切なCIS Operating Systemベンチマークに対して構成を検証する必要があります。OSの設定を検証できるCISパートナーのベンチマークツールのリストは以下のURLからご覧いただけます。
CIS Center for Internet Security
https://www.cisecurity.org/
たとえば、CIS Oracle Linux 7の場合、以下のツールがあります（アルファベット順）。

Additional Host Hardening Recommendations

CISのベンチマーク以外に、以下のような追加のホスト・ハードニングの推奨事項と考慮すべき情報があります。
  • GrsecurityとPAXの利用
  • NCCグループによるホスト・ハードニングの推奨事項

Grsecurity and PaX

grsecurityプロジェクトは、システムの全体的なセキュリティを強化するさまざまなパッチをLinuxカーネルに提供します。これには、アドレス空間の保護、拡張された監査およびプロセス制御が含まれます。
PaXは、スタックなどのデータメモリに対し、非実行可能プログラムメモリおよび書き込み不可能プログラムメモリとしてフラグを立てます。PaXはまた、アドレス空間レイアウトのランダム化を提供します。
Dockerで利用するカーネルでGrsecurityとPAXを実行することができます。このときDockerの構成を変更する必要はありません。セキュリティ機能はホスト全体に適用されるため、全てのコンテナに適用されます。grsecurityとPaXを調査して、それらを運用環境で使用できるかどうかを判断することができます。詳細は以下のURLをご覧ください。
grsecurity
http://grsecurity.net/

NCC Group Host Hardening Recommendations

NCCグループのホワイトペーパーには、Linuxコンテナをハードニングする上での追加の推奨事項が含まれています。
NCC Group Whitepaper
Understanding and Hardening
Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf
There is overlap between these recommendations and the CIS Dockerベンチマークとこの推奨事項には重複する箇所が2箇所あります。
  • 10.1 Generation Container Recommendations
  • 10.3 Docker Specific Recommendations 
追加のホストハードニング項目も含まれています。
  • Keep the kernel as up to date as possible（カーネルを最新に保つ）
  • Typical sysctl hardening should be applied. 
（通常のsysctlハードニングを適用する）
  • Isolate storage for containers and ensure appropriate security.（コンテナのストレージを分離して適切なセキュリティを確保する）
  • Control device access and limit resource usage using Control Groups (cgroups)（デバイスアクセスを管理し、Control Group (cgroup)を使ってリソース利用を制限する）
詳細を調べたい場合には、以下のURLをご覧ください。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf

Additional Container Runtime Recommendations

CISのDockerに対する推奨事項以外に、検討すべき追加のコンテナランタイムの推奨事項があります。
  • 手動もしくはDocker Slimなどのツールを使用して作成したカスタムのseccompプロファイルを使用する
  • Docker Security Enhanced Linux（SELinux）プロファイルを活用する
  • Docker起動時に追加の制限付きLinuxカーネル機能を指定する
  • ホストサーバー上でDockerのみを実行することで、分離を向上させ、攻撃の危険性を減らす
  • NCCグループの推奨に基づき、追加のコンテナハードニングを実施する

Run with a Custom seccomp Profile

セキュアコンピューティングモード（seccomp）は、コンテナ内で利用可能なアクションを制限するために使用できるLinuxカーネル機能です。この機能は、Dockerがseccompを伴ってビルドされていて、カーネルでCONFIG_SECCOMPが有効化されている場合にのみ使用できます。Oracle Linux 7はseccompをサポートしており、デフォルトではDockerはseccompプロファイルで動作します。
デフォルトのseccompプロファイルは、seccompを使ってコンテナを実行するための適切なデフォルト設定を提供し、300以上のシステムコールのうち約44を無効にします。デフォルトのseccompプロファイルを変更することはお勧めしませんが、以下のオプションを使い、カスタムプロファイルを指定して実行することができます。
--security-opt seccomp = /path/to/seccomp/profile.json
seccompのデフォルトプロファイルの詳細については以下をご覧ください。
Seccomp security profiles for Docker
https://docs.docker.com/engine/security/seccomp/#passing-a-profile-for-a-container
Docker運用環境に対して既定のseccompプロファイルが十分ではない場合は、カスタムプロファイルを作成して実行することもできます。Docker Slimなどのツールが、静的解析と動的解析によってカスタムseccompプロファイルを生成するのに役立つことでしょう。
DockerSlim (docker-slim): Optimize and secure your Docker containers (free and open source)
https://github.com/docker-slim/docker-slim

Run with SELinux

SELinux（Security-Enhanced Linux）は、強制アクセス制御（MAC）を含むアクセス制御セキュリティポリシーをサポートするためのメカニズムを提供するLinuxカーネルセキュリティモジュールです。Dockerコンテナ起動時にSELinuxを有効化できます。
SELinuxを有効化する前に、SELinuxがインストールされていることを確認してください。
yum install selinux-policy
DockerのSELinuxモジュールを有効化します。
semodule -v -e docker
SELinuxがDocker起動時に有効化されるように指定します。
# vi /etc/sysconfig/docker
OPTIONS='--selinux-enabled --group=docker -g /scratch/docker'

Run with Restricted Capabilities

Dockerは、制限されたLinuxカーネル機能でコンテナを実行します。追加の機能を指定して、環境の要件に基づいて削除できます。 詳細については以下のURLをご覧ください。
Linux kernel capabilities
https://docs.docker.com/engine/security/security/#linux-kernel-capabilities

Run Only Docker on Server

リソースの隔離と攻撃の危険性を減らすために、サーバー上でDockerのみを実行することをお勧めします。他のサービスはDockerコンテナに移動する必要があります。

NCC Group Docker Container Hardening Recommendations

NCCグループのホワイトペーパーには、Linuxコンテナを強化するための推奨事項が追加されています。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf
CISベンチマークと以前の章でリストアップした推奨事項で、以下の2箇所に重複する部分があります。
  • 10.1 Generation Container Recommendations
  • 10.3 Docker Specific Recommendations 
追加のDockerコンテナハードニング項目も含まれています。
  • Control device access and limit resource usage using Control Groups (cgroups)（Control Groups (cgroups)を使ってデバイスアクセスを管理しリソース利用を制限する）
  • Isolate containers based on trust and ownership. Have one application per container if feasible.
    （信頼と所有権に基づいてコンテナを分離する。可能であれば、1コンテナ1アプリケーションとする）
  • Use layer two and layer three firewall rules to limit container to host and guest to guest communication.
    （L2、L3ファイアウォール・ルールを使ってコンテナからホスト、ゲスト間の通信を制限する）
  • Use Docker container auditing tools such as Clair, drydock, and Project Natilus.
    （Clair、drydock、Project NatilusといったDockerコンテナの監査ツールを使う）
これらの推奨事項の詳細は、以下をご覧ください。
NCC Group Whitepaper
Understanding and Hardening Linux Containers
June 29, 2016 – Version 1.1
https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/april/ncc_group_understanding_hardening_linux_containers-1-1.pdf

Ensuring the Security of WebLogic Server Running in Your Kubernetes Production Environment

References to Kubernetes Security Resources

以下の推奨事項は、列挙したような様々なソースのドキュメントやホワイトペーパーを基にしています。

Summary of Recommendations

環境を保護するための推奨事項は
  1. Kubernetesの構成をCIS Kuberbetesベンチマークを使って検証する。これは手作業でも、3rdパーティ製ツールを使っても実施できる。
  2. CISで未対応のKubernetesランタイムに対する追加の推奨事項を評価する。
詳細は以下で説明します。

Validate Your Kubernetes Configuration Using the CIS Kubernetes Benchmark

The Center for Internet Security (CIS) は、Kubernetesのベンチマークを作成しています。このベンチマークには、約250ページにわたって、Kubernetesを安全に構成するための一連の詳細な推奨事項が含まれています。この推奨事項は、さまざまなKubernetesコンポーネントに適用されます。推奨事項は以下のトピックで構成されています。
  • API Server、Scheduler、Controller Manager、構成ファイルやetcdを含む、マスターノードのセキュリティ構成
  • Kubelet、構成ファイルなどを含む、ワーカーノードのセキュリティ構成
  • Federated Deployments（Federation API ServerやFederation Controller Managerなど）
詳細情報は以下のURLをご覧ください。
CIS Kubernetes Benchmark
https://www.cisecurity.org/benchmark/kubernetes/
CIS Kubernetesベンチマークの各推奨事項に対して、手動または自動ツールを使用して構成を検証する必要があります。以下のURLにKubernetes設定を検証できるCISパートナーのベンチマークツールのリストがあります。このリストには以下のものが含まれます（アルファベット順）。
CIS Center for Internet Security
http://www.cisecurity.org
注：CISベンチマークは、商用使用のためのライセンスが必要です。詳細については、以下のURLをご覧ください。
CIS SecureSuite Membership Terms of Use
https://www.cisecurity.org/cis-securesuite/cis-securesuite-membership-terms-of-use/

Additional Container Runtime Recommendations

CIS Kubernetesベンチマークの推奨事項以外に、コンテナランタイムに対する検討すべき追加の推奨事項があります。

Images

イメージは脆弱性があってはならず、信頼できるレジストリまたは個人レジストリから取得する必要があります。セキュリティ上の脆弱性がないことを確認するためにイメージのスキャンを実行する必要があります。サードパーティ製のツールを使用してCVEスキャンを実行し、これらのツールをビルドプロセスに統合する必要があります。
詳細は以下のURLをご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Security Context and Pod Security Policy

セキュリティ・コンテキストを使って、Podもしくはコンテナレベルでセキュリティポリシーを設定することができます。セキュリティコンテキストを使って以下のことが可能です。
  • コンテナをroot以外のユーザーで実行する
  • コンテナで利用する機能を管理する
  • ルートファイルシステムを読み取り専用にする
  • Podからrootとして実行しているユーザーでコンテナを使用しないようにする
詳細は以下のリンクをご覧ください。
Configure a Security Context for a Pod or Container
https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Secure Access to Nodes

ホストリソースへの不正アクセスというリスクを削減するため、SSHアクセスを使ったKubernetesノードへのアクセスは避けるべきです。SSHではなく、kubectl exec を使ってください。問題のデバッグが必要な場合は、SSHアクセスを許可した別のステージング環境を作成してください。

Separate Resources

Kubernetes名前空間を使用すると、作成されたリソースを論理的に名前のついたグループに分割できます。ある名前空間で作成されたリソースは、他の名前空間から隠すことができます。追加の名前空間を作成して、リソースやユーザーを追加した名前空間にアタッチできます。メモリ、CPU、およびPodがアタッチされた名前空間に対し、リソースクォータを利用できます。
詳細は、以下のURLをご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html

Manage Secrets

secretには、パスワード、トークン、キーなどの機密データが含まれています。secretは、データボリュームとしてマウントすることも、Pod内のコンテナが使用する環境変数として公開することもできます。また、Podに直接公開せずに、システムの他の部分で使用することもできます。 以下のことを実施しておく必要があります。
  • secretへのユーザーアクセスやPodアクセスを管理する
  • secretをセキュアに保存する
  • secretにはファイルや環境変数を使わないようにする
詳細は以下のURLをご覧ください。
Secrets
https://kubernetes.io/docs/concepts/configuration/secret/

Networking Segmentation

さまざまなアプリケーションが同じKubernetesクラスタで実行されないようにネットワークを分割します。これにより、ある侵害されたアプリケーションが近隣のアプリケーションを攻撃するリスクが軽減されます。ネットワーク分割は、許可されていない限り、コンテナが他のコンテナと通信できないことを保証します。
詳細は以下のImplement Network Segmentationの項をご覧ください。
Security Best Practices for Kubernetes Deployment
http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html
-
カテゴリ , , ,

0 件のコメント:

コメントを投稿

登録: コメントの投稿 (Atom)