セキュリティのベスト・プラクティス

ベスト・プラクティス: 計画エクスポージャ・レベル

Kubernetes Engineを使用して作成するクラスタのセキュリティ計画を実装する前に、次の質問に答えることをお薦めします:

• クラスタにはどのくらいのインターネット・エクスポージャが必要ですか。
• ワークロードをVCNまたは外部(あるいはその両方)に内部的にインターネットに公開するには、どのようにしますか。
• ワークロードをどのように拡張する予定ですか。
• クラスタが消費するOracleサービスのタイプを教えてください。

前述の質問に回答した後、次のベスト・プラクティスを検討することをお薦めします。

• ベスト・プラクティス: プライベート・クラスタの作成

  ワークロードをインターネットではなくVCNに内部的にのみ公開する場合は、Kubernetes APIエンドポイントを含むVCNネイティブ・クラスタをプライベート・サブネットに作成することをお薦めします。このようなクラスタは、プライベート・クラスタと呼ばれることもあります。

  プライベート・クラスタを構成すると、すべてのコントロール・プレーン・コンポーネント(クラスタのKubernetes APIエンドポイントを含む)がプライベートRFC 1918ネットワーク領域内にあります。その結果、アクセスは制限され、すべてのトラフィックはOracleのネットワーク内に保持されます。特定のVCNへのKubernetes APIへのアクセスをロックダウンできます。

  プライベート・クラスタを使用しない場合、クラスタのKubernetes APIエンドポイントにはパブリックIPv4アドレスがあり、APIへのすべてのトラフィック(クラスタのノード・プールからのトラフィックを含む)がパブリック・ネットワーク領域を経由します。

  プライベートKubernetesクラスタの発表を参照してください。

• ベスト・プラクティス: すべてのアプリケーションをプライベート・サブネットに配置

  インターネットへのサービスの露出を減らしたい場合は、アプリケーション・ワークロードを実行しているワーカー・ノード・コンピュート・インスタンスをプライベート・サブネットに配置し、それらにアクセスするためのロード・バランサを設定することをお薦めします。

  サービス・インスタンスをインターネットから分離することで、サービスの攻撃対象領域が削減されます。ほとんどのサービス・インスタンスは、インターネットに直接公開する必要はありません。

  クラスタの作成とデプロイメントのためのネットワーク・リソース構成を参照してください。

• ベスト・プラクティス: ネットワーク・セキュリティ・グループを使用したクラスタ・トラフィックの制限

  クラスタを作成およびデプロイするVCNに対して、(セキュリティ・リストではなく)ネットワーク・セキュリティ・グループにセキュリティ・ルールを定義することをお薦めします。

  Kubernetes Engineは、デフォルトで必要なセキュリティ・ルールを作成しますが、特定の要件を満たすように変更できます。

  ネットワーク・セキュリティ・グループまたはセキュリティ・リスト(あるいはその両方)のセキュリティ・ルール構成を参照してください。

ベスト・プラクティス: セキュリティ・パッチを定期的に適用

ワーカー・ノードで実行されているオペレーティング・システムを定期的に更新して、最新のセキュリティ・パッチを適用することをお薦めします。

Kubernetes Engineによって作成されたクラスタ内のワーカー・ノードは、強化されたLinuxイメージを実行します。

ワーカー・ノードで実行されているサービスにはコンテナ・ランタイム、kubeletおよびkube-proxyが含まれるため、ワーカー・ノードのオペレーティング・システムを堅牢かつセキュアに保つことが重要です。

もう1つのベスト・プラクティスは、ワーカー・ノードにCenter for Internet Security (CIS) Kubernetesベンチマークを使用することです。

「更新されたプロパティを持つワーカー・ノードの作成」を参照してください。

ベスト・プラクティス: Kubernetesネットワーク・ポリシーとネットワーク・セキュリティ・グループ(NSG)の組合せを使用します

Kubernetesネットワーク・ポリシーをOCIネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リスト(あるいはその両方)と組み合せて実装することを検討することをお薦めします。

Kubernetesネットワーク・ポリシー(ポッドレベルのネットワーク通信を保護するため)とNSGまたはOCIセキュリティ・リスト(あるいはその両方)を組み合せて、ホストレベルのネットワーク通信を保護できます。

ネットワーク・セキュリティを参照してください。

ベスト・プラクティス: ネットワーク・セキュリティ・グループ(NSG)をInfrastructure-as-Codeツール(Terraformなど)と組み合せて使用

TerraformなどのInfrastructure-as-Codeツールとともにロード・バランシング・コントローラを実装する場合は、セキュリティ・リストではなくネットワーク・セキュリティ・グループ(NSG)にセキュリティ・ルールを使用することをお薦めします。

Kubernetesを大規模に運用するには、通常、インフラストラクチャ・リソースの状態を追跡するためにTerraformなどのInfrastructure as Codeツールを使用します。たとえば、インフラストラクチャを元の状態および目的の状態に維持するには、通常、Terraform構成を実行して再実行します。ただし、Cloud-controller-managerがサブネットが使用するセキュリティ・リスト内のセキュリティ・ルールを追加または更新すると、LoadBalancerタイプのKubernetesサービスで潜在的な競合が発生します。セキュリティ・リスト内のセキュリティ・ルールに対する変更は、Terraform構成には反映されません。その結果、次回Terraformを実行すると、セキュリティ・リスト内のセキュリティ・ルールへの変更は元の状態から「ドリフト」としてフラグが付けられ、Terraform構成を適用すると破棄されます。セキュリティ・ルールがないと、LoadBalancerタイプのサービスをプロビジョニングするロード・バランサまたはネットワーク・ロード・バランサがトラフィックを処理したり、アプリケーション・ポッドをホストするノードと通信できないため、クラスタにデプロイされたアプリケーションが失敗することがあります。

cloud-controller-managerを構成して、サブネットのセキュリティ・リスト内のセキュリティ・ルールを管理しないか、ロード・バランサまたはネットワーク・ロード・バランサのエグレス・セキュリティ・ルールのみを管理できます。ただし、どちらの場合も、新しいサービスがクラスタにデプロイされるたびに選択したポートを手動で構成するか、ノード・ポート範囲を完全に開く必要があります。どちらのソリューションも理想的ではありません。1つは実行時の手動作業を含み、もう1つは潜在的なセキュリティ脆弱性をもたらすためです。

cloud-controller-managerがセキュリティ・ルールを追加または更新することでセキュリティ・リスト・リソースを変更する可能性を回避し、その後Terraform構成を適用したときにそれらの変更が破棄されるため、cloud-controller-managerはNSGを使用することをお薦めします。NSGに定義されたセキュリティ・ルールは、独自のOCIDsを持つ独自の権利を持つリソースであり、NSG自体から独立しています。NSGセキュリティ・ルールを変更してもNSGリソース自体は変更されないため、Terraform構成を適用しても変更は破棄されません。

詳細は、NSGおよびセキュリティ・リストのセキュリティ・ルールを管理するためのoci.oraclecloud.com/security-rule-management-mode注釈の使用を参照してください。

ベスト・プラクティス: シークレットおよび証明書を定期的にローテーションします

シークレット、資格証明および証明書の存続期間を短く設定し、ローテーションを自動化することをお薦めします。

ベスト・プラクティス: すべてのアプリケーションを非特権ユーザーとして実行します。

すべてのアプリケーションを非特権ユーザーとして実行することをお勧めします。これは、多くの規制基準の要件でもあります。

非特権ユーザーとしてアプリケーションを実行すると、攻撃者が脆弱性(リモート・コード実行の脆弱性など)を悪用した場合、非特権ユーザーに与えられる制限付きアクセスに制限されます。また、攻撃者は、攻撃をエスカレートして追加の権限を取得したり、コンテナから抜け出したり、カーネル・バグを介してルート・アクセスを取得したりすることがより困難になります。

ベスト・プラクティス: コンテナを不変として扱う

コンテナ・ルート・ファイルシステムを読取り専用として定義することをお薦めします。コンテナのルート・ファイルシステム内のライブラリおよびバイナリの更新を許可する場合は、クラスタ全体を攻撃に対して脆弱にします。

コンテナの一時的な性質により、セキュリティ上の大きなメリットが得られます。アプリケーションとその即時環境が全体としてデプロイおよびアップグレードされるため、システム全体に対する永続的な攻撃がより困難になります。ルートファイルシステムの変更を防止することで、脅威の可能性を減らし、潜在的な影響を減らすことによって、セキュリティーを強化します。

ベスト・プラクティス: SSL処理をイングレス・コントローラまたはロード・バランサ(許可されている場合)にオフロードすることを検討してください

組織のネットワーク・セキュリティ・ポリシーによって柔軟性が提供される場合は、SSL処理をイングレス・コントローラまたはロード・バランサにオフロードすることをお薦めします。

イングレス・コントローラ(Traefik、NGINXオープン・ソースなど)を使用すると、クラスタの外部から発信するHTTP/Sトラフィックを、クラスタ内で実行されているサービスにインテリジェントにルーティングできます。Oracle Cloud Infrastructure Load Balancerサービスでは、転送中のデータを暗号化するためのトランスポート暗号化プロトコル(SSLおよびTLS)がサポートされています。

暗号化されたトラフィックは、ネットワーク内の様々な場所(ロード・バランサ、イングレス・リソース、ポッドなど)で終了できます。SSL接続を終了する方法と場所は、最終的に組織のネットワーク・セキュリティ・ポリシーによって決まります。たとえば、組織のネットワーク・セキュリティ・ポリシーでエンドツーエンドの暗号化が必要な場合は、ポッドでトラフィックを復号化する必要があります。ポッドは最初のハンドシェイクを確立するサイクルを費やす必要があり、SSL/TLS処理が非常にCPU集中であるため、トラフィックの復号化によってポッドに追加の負荷がかかります。したがって、組織のネットワーク・セキュリティ・ポリシーで柔軟に実行できる場合は、SSL処理をイングレス・コントローラまたはロード・バランサにオフロードします。

監査、ロギングおよび監視のベスト・プラクティス

監査、ロギングおよび監視を有効にする場合は、次のベスト・プラクティスを考慮することをお薦めします。

• ベスト・プラクティス: ログを定期的に確認

  Kubernetes API Server監査ログと、クラスタ内のワーカー・ノードで実行されているアプリケーションのアプリケーション・ログの両方を定期的に確認することをお薦めします。ログを定期的にチェックすると、クラスタ内の脅威または脆弱性を識別できます。

  Kubernetesクラスタの監視を参照してください。

• ベスト・プラクティス: 監査ロギングの有効化

  監査ロギングを有効にし、セキュリティー保護されたリポジトリに監査ログを保存して、侵害が発生した場合に将来の分析を行うことをお勧めします。

  Kubernetes APIサーバー監査ログの表示を参照してください

• ベスト・プラクティス: Kubernetesクラスタベースのロギングの使用

  Kubernetesクラスタベースのロギングを使用して、コンテナ・アクティビティを中央ロギング・サブシステムに記録することをお薦めします。Kubernetesクラスタ内の各コンテナの標準出力および標準エラー出力は、Elasticsearchなどのツールに(各ノードで実行されているFluentdなどのエージェントを使用して)取り込み、Kibanaで表示できます。

  Kubernetesドキュメントのロギング・アーキテクチャを参照してください。

• ベスト・プラクティス: クラスタ・コンポーネントのモニター

  Prometheus、Grafana、Jaegerなどのツールを使用して、コンテナ、ポッド、アプリケーション、サービスおよびその他のクラスタ・コンポーネントを監視することをお薦めします。

• ベスト・プラクティス: ネットワーク・トラフィック・メタデータをログに記録し、定期的に分析します

  Oracle Cloud Infrastructure LoggingサービスでVCNフロー・ログを有効にして、ソースおよび宛先のIPアドレスやポートなど、VCNを経由するトラフィックに関するメタデータを、受け入れ/ドロップされたパケットとともに取得することをお薦めします。取得したら、メタデータを定期的に分析して、ポッド間を含むVCN内のリソース間の疑わしいアクティビティまたは異常なアクティビティを特定します。Oracle VCNフロー・ログを使用したネットワーク・トラフィックの監視を参照してください。

Kubernetesクラスタの監視を参照してください。

ベスト・プラクティス: 小規模でセキュアなコンテナ・イメージの使用

コンテナのアプリケーションに必要なパッケージ、ライブラリおよびツールのみを含む、小規模でセキュアなコンテナ・イメージを構築することをお薦めします。

新しい開発者は、ベース・イメージ内のパッケージやライブラリの大部分を必要としない場合でも、ベース・イメージの使用を間違えることがよくあります。ストレージ領域を少なくする必要がある小さいイメージを選択することをお薦めします。小さいイメージを使用すると、イメージをより速くプルおよび構築できます。また、イメージが小さいと、セキュリティの問題の可能性が低くなります。

コンテナ・イメージのサイズをさらに小さくするには、コンテナのアプリケーションに必要なツールのみをインストールすることをお薦めします。本番コンテナにはデバッグ・ツールを含めないでください。

アプリケーションがポッド開始時にネットワーク・ツールのみを必要とする場合、長時間実行アプリケーションのイメージにcurlなどの悪用可能なツールを配置するかわりに、個別のinitコンテナを使用するか、よりKubernetesネイティブな方法(ConfigMapsなど)を使用してデータを配信することを検討することをお薦めします。

また、コンテナ・イメージを最新の状態に保ち、ベース・イメージとインストールするサードパーティ・ツールの両方の新しいバージョンを確認することをお薦めします。

ベスト・プラクティス: 資格証明エクスポージャの制限

アプリケーション・コード内に資格証明を定義しないことをお薦めします。かわりに、デジタル・ボールト(Oracle Cloud Infrastructure Vaultなど)を使用して、デジタル・キーおよび資格証明を格納および取得します。

ベスト・プラクティス: 適切な認証トークンを使用してクラスタにアクセスします

kubectlおよびKubernetes Dashboardを使用してクラスタにアクセスする場合は、コマンドによって生成された認証トークンのみをクラスタのkubeconfigファイルで使用することをお薦めします。他のプロセスおよびツールがクラスタにアクセスする場合は、認証にユーザー固有でない認証トークンを使用します。

クラスタ用にkubeconfigファイルを設定すると、デフォルトでは、このファイルには、短期間の、クラスタの有効範囲が指定されたユーザー固有の認証トークンを生成するOracle Cloud Infrastructure CLIコマンドが含まれています。CLIコマンドで生成される認証トークンは、kubectlおよびKubernetes Dashboardを使用してクラスタにアクセスする個々のユーザーを認証するのに適しています。

ただし、生成される認証トークンは、継続的統合や継続的配信(CI/CD)ツールなど、クラスタにアクセスするプロセスおよびツールの認証には適していません。クラスタへのアクセスを確保するために、このようなツールには、ユーザー固有でない長期間の認証トークンが必要です。1つのソリューションとして、Kubernetesサービス・アカウントを使用します。

Kubeconfigファイルへのサービス・アカウント認証トークンの追加を参照してください。

ベスト・プラクティス: RoleBindingsおよびClusterRoleBindingsの作成時に最小特権アクセスを構成します

特定の機能の実行に必要な権限セットを含むKubernetes RoleBindingsおよびClusterRoleBindingsのみを定義することをお薦めします。

デフォルトでは、ユーザーにKubernetes RBACロール(またはclusterroles)は割り当てられていません。したがって、新しいロール(またはclusterrole)を作成する前に、適切な権限を持つロール(またはclusterrole)を割り当てる必要があります。cluster-admin clusterroleを含む、このような多くのロールおよびclusterroleは、常にデフォルトで作成されます(詳細は、Kubernetesのドキュメントのデフォルト・ロールおよびロール・バインディングに関する項を参照)。cluster-admin clusterroleは、基本的にスーパーユーザー権限を付与します。cluster-admin clusterroleを付与されたユーザーは、特定のクラスタ内のすべてのネームスペースで任意の操作を実行できます。

アクセス制御およびKubernetesエンジン(OKE)についてを参照してください。