原文はこちら。
https://blogs.oracle.com/weblogicserver/security-best-practices-for-weblogic-server-running-in-docker-and-kubernetes
これらのベストプラクティスは、以下のドキュメントにある一般的なWebLogic Serverの推奨事項に追加されるものです。
これらのベンチマークには、ホストOSを安全に設定するための一連の詳細な推奨事項が含まれています。たとえば、CIS Oracle Linux 7ベンチマークには、200を超える推奨事項と300ページ以上の指示が含まれています。この推奨事項は、Linux構成におけるすべての側面に適用されます。
詳細は、ベンチマーク文書をご覧ください。
PaXは、スタックなどのデータメモリに対し、非実行可能プログラムメモリおよび書き込み不可能プログラムメモリとしてフラグを立てます。PaXはまた、アドレス空間レイアウトのランダム化を提供します。
Dockerで利用するカーネルでGrsecurityとPAXを実行することができます。このときDockerの構成を変更する必要はありません。セキュリティ機能はホスト全体に適用されるため、全てのコンテナに適用されます。grsecurityとPaXを調査して、それらを運用環境で使用できるかどうかを判断することができます。詳細は以下のURLをご覧ください。
デフォルトのseccompプロファイルは、seccompを使ってコンテナを実行するための適切なデフォルト設定を提供し、300以上のシステムコールのうち約44を無効にします。デフォルトのseccompプロファイルを変更することはお勧めしませんが、以下のオプションを使い、カスタムプロファイルを指定して実行することができます。
SELinuxを有効化する前に、SELinuxがインストールされていることを確認してください。
詳細は以下のURLをご覧ください。
詳細は、以下のURLをご覧ください。
詳細は以下のImplement Network Segmentationの項をご覧ください。
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
以下の推奨事項は、列挙したような様々なソースのドキュメントおよびホワイトペーパーを基にしています。- Docker Security
https://docs.docker.com/engine/security/security/ - Center for Internet Security (CIS) Docker Benchmarks
https://www.cisecurity.org/benchmark/docker/ - CIS Linux Benchmarks
https://www.cisecurity.org/benchmark/oracle_linux/ - NCC Group: Hardening Linux Containers
https://www.nccgroup.trust/us/our-research/understanding-and-hardening-linux-containers/ - Seccomp profiles
https://docs.docker.com/engine/security/seccomp/ - Best Practices for Writing Docker Files
https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/ - Understanding Docker Security and Best Practices
https://blog.docker.com/2015/05/understanding-docker-security-and-best-practices/
Summary of Recommendations
本番環境を保護するにあたっての推奨事項は以下の通りです。- CIS Dockerベンチマークを使用してDockerの設定を検証します。これは、サードパーティのツールを使用して手動または自動で行うことができます。
- 適切なCIS Operating Systemベンチマークを使用して、ホストOSの設定を検証します。
- CISベンチマークで未対応の追加のホストハードニングの推奨事項を評価します。
- 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 BenchmarksCIS Dockerベンチマークの各推奨事項に対して、手動または自動ツールを使用して構成を検証する必要があります。Dockerの構成を検証できるCISパートナーのベンチマークツールのリストは以下のURLからご覧いただけます。
https://www.cisecurity.org/benchmark/docker/
CIS Center for Internet Securityベンチマークツールには、次のものが含まれます（アルファベット順）。
https://www.cisecurity.org/
- Cavirin
https://www.cisecurity.org/partner/cavirin/ - Docker Bench for Security
https://github.com/docker/docker-bench-security - Qualys
https://www.cisecurity.org/partner/qualys/ - Symantec
https://www.cisecurity.org/partner/symantec/ - Tenable
https://www.cisecurity.org/partner/tenable/ - Tripwire
https://www.cisecurity.org/partner/tripwire/ - TwistLock
https://www.twistlock.com - VMware
https://blogs.vmware.com/security/2015/05/vmware-releases-security-compliance-solution-docker-containers.html
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手動または自動ツールを使用して、適切なCIS Operating Systemベンチマークに対して構成を検証する必要があります。OSの設定を検証できるCISパートナーのベンチマークツールのリストは以下のURLからご覧いただけます。
https://www.cisecurity.org/cis-benchmarks/
CIS Center for Internet Securityたとえば、CIS Oracle Linux 7の場合、以下のツールがあります（アルファベット順）。
https://www.cisecurity.org/
- NNT
https://www.cisecurity.org/partner/nnt/ - Qualys
https://www.cisecurity.org/partner/qualys/ - Tenable
https://www.cisecurity.org/partner/tenable/ - Tripwire
https://www.cisecurity.org/partner/tripwire/
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 WhitepaperThere is overlap between these recommendations and the CIS Dockerベンチマークとこの推奨事項には重複する箇所が2箇所あります。
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
- 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)を使ってリソース利用を制限する）
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プロファイルを変更することはお勧めしませんが、以下のオプションを使い、カスタムプロファイルを指定して実行することができます。
seccompのデフォルトプロファイルの詳細については以下をご覧ください。--security-opt seccomp = /path/to/seccomp/profile.json
Seccomp security profiles for DockerDocker運用環境に対して既定のseccompプロファイルが十分ではない場合は、カスタムプロファイルを作成して実行することもできます。Docker Slimなどのツールが、静的解析と動的解析によってカスタムseccompプロファイルを生成するのに役立つことでしょう。
https://docs.docker.com/engine/security/seccomp/#passing-a-profile-for-a-container
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がインストールされていることを確認してください。
DockerのSELinuxモジュールを有効化します。yum install selinux-policy
SELinuxがDocker起動時に有効化されるように指定します。semodule -v -e 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 WhitepaperCISベンチマークと以前の章でリストアップした推奨事項で、以下の2箇所に重複する部分があります。
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
- 10.1 Generation Container Recommendations
- 10.3 Docker Specific Recommendations
- 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
以下の推奨事項は、列挙したような様々なソースのドキュメントやホワイトペーパーを基にしています。- Security Best Practices for Kubernetes Deployment: http://blog.kubernetes.io/2016/08/security-best-practices-kubernetes-deployment.html
- CIS Kubernetes Benchmarks
https://www.cisecurity.org/benchmark/kubernetes/ - Kubelet Authentication and Authorization
https://kubernetes.io/docs/admin/kubelet-authentication-authorization/ - RBAC Authorization
https://kubernetes.io/docs/admin/authorization/rbac/ - Pod Security Policies RBAC
https://kubernetes.io/docs/concepts/policy/pod-security-policy/#working-with-rbac - Auditing
https://kubernetes.io/docs/tasks/debug-application-cluster/audit/ - etcd Security Model
https://coreos.com/etcd/docs/latest/op-guide/security.html
Summary of Recommendations
環境を保護するための推奨事項は- Kubernetesの構成をCIS Kuberbetesベンチマークを使って検証する。これは手作業でも、3rdパーティ製ツールを使っても実施できる。
- 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など）
CIS Kubernetes BenchmarkCIS Kubernetesベンチマークの各推奨事項に対して、手動または自動ツールを使用して構成を検証する必要があります。以下のURLにKubernetes設定を検証できるCISパートナーのベンチマークツールのリストがあります。このリストには以下のものが含まれます（アルファベット順）。
https://www.cisecurity.org/benchmark/kubernetes/
CIS Center for Internet Security
http://www.cisecurity.org
- Twistlock
www.twistlock.com - NeuVector
http://neuvector.com/blog/open-source-kubernetes-cis-benchmark-tool-for-security/ - Kube Bench
https://github.com/aquasecurity/kube-bench
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にはファイルや環境変数を使わないようにする
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