X

A blog about Oracle Technology Network Japan

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

Guest Author

※本記事は、Manish Kapur [DirectorOracle Cloud Platform]による"5 Best Practices for Kubernetes Security"を翻訳したものです。

2020年4月15日


Kubernetesはこの3年で急速に利用者を拡大し、多くの企業にて本番環境にデプロイされています。Kubernetesは基本的にコア・ソフトウェアのセキュリティ原則に従いますが、一部のセキュリティ要素はエンド・ユーザーが責任を担うことになります。クラウド・プロバイダとユーザーとの間で、セキュリティ責任が共有されるのと同様、クラウド・プロバイダから提供されるマネージドKubernetesサービスにも、共有されるセキュリティ責任があります。Oracle Cloud Infrastructure Container Engine for Kubernetes(Oracle Kubernetes EngineまたはOKEとも表記される)やAzure Kubernetes ervice(AKS)といったマネージドKubernetesサービス・クラウド・プロバイダは一般的に、Kubernetesクラスタのコントロール・プレーン(APIサーバー、スケジューラ、etcd、コントローラ)の運用および安全性に責任を負い、一方でマネージド・サービスのユーザーは、データ・プレーン(ノード・プール、受信、ネットワーキング、サービス・メッシュなど)の安全性に責任を負います。

私はKubernetes Oracle Linux VagrantのBoxを使用して、3年前からKubernetesに携わるようになりました。そうした私の経験を基に、本ブログでは、Kubernetesの5つのセキュリティ・プラクティスを紹介したいと思います。

  1.  ロール・ベースのアクセス制御(RBAC)を使用する
  2. Secretは必ずシークレットにする
  3. ノードとポッドの安全性を確保する
  4. コンテナのセキュリティ・リスクを排除する
  5. 監査、ロギング、モニタリングは必須

では、それぞれについて説明します。

 

ロール・ベースのアクセス制御(RBAC)を使用する

ロール・ベースのアクセス制御(RBAC)では、Kubernetes APIにアクセスできるユーザーおよびその権限レベルを制御できます。Kubernetesでは通常、RBACがデフォルトで有効になっています。しかし、RBACが有効になっていない非常に古いKubernetesからアップグレードした場合は、念のためRBACの設定にチェックを付けて、これを有効にする必要があります。ただ、RBACを有効にするだけでは十分ではありません。権限許可のポリシーも管理し、これを適切に使用する必要があります。RBACを使用すると、ユーザーやユーザー・グループを限定して、必要なアクションやタスクにしかアクセスできないようにすることができます。その際は、最小権限の原則に従い、ユーザーおよびKubernetesのサービス・アカウントには必要最小限の権限のみが付与されるようにします。またクラスタ全体を対象にした権限は付与しないようにし、絶対的に必要でない限りクラスタ管理者の権限は誰にも付与しないようにします。詳細は、Kubernetesの公式のRBACドキュメントを参照してください。Oracle Container Engine for Kubernetesを使用して作成・管理されるKubernetesクラスタの運用では、Oracle Cloud Infrastructure Identity and Access Management(OCI IAM)にて完全なアクセス制御が可能です。詳細は、こちらのドキュメントにてご確認ください。


 
Secretは必ずシークレットにする

Secretには、パスワードやトークン、sshキーといった重要なデータが含まれています。キーやパスワード、トークンなどのアーティファクトにてポッドを安全に起動するためです。そのためポッドを起動するには、通常、そのSecretにアクセスする必要があります。サービス・アカウントが作成されると、その認証トークンを保存するSecretが自動的に生成されます。またKubernetesでは、Restでの暗号化をサポートしています。これによりetcdのSecretリソースが暗号化されるため、etcdのバックアップにアクセスされ、そのSecretの内容を閲覧されるといったことを回避できます。バックアップが暗号化されていない場合や、攻撃者によってetcdへの読み取りアクセスが取得されている場合には、暗号化によって防御レベルが強化されます。またこちらで説明されているように、SSL/TLSを使用して、ユーザーとAPIサーバー間の通信およびAPIサーバーからKubeletへの通信を保護するようにします。Secretや資格証明の使用期限を短くして、攻撃者によるこれらの使用を難しくすることも、推奨されます。資格証明の使用期限を短く設定し、資格証明のローテーションを自動化することもお勧めです。なお、KubernetesクラスタのSecretにアクセスする必要のあるサードパーティとの統合がある場合は、注意が必要です。この場合は、必要なRBACの権限とアクセス権を慎重に検討する必要があります。さもないと、クラスタのセキュリティ・プロファイルが漏洩してしまうかもしれません。Oracle Kubernetes Engineを使用している場合は、Encrypting Kubernetes Secrets at Rest in Etcdにて詳細をご確認ください。


 
ノードとポッドの安全性を確保する

ノード:Kubernetesのノードは、仮想マシンまたは物理マシンになり得るワーカーノードで、一般的にLinux OSにて動作します。ノードにて実行されるサービスには、コンテナ・ランタイム、kubelet、kube-proxyがあります。ノードで実行されるOSの堅牢性と安全性を確保することは重要であり、これはクラウド・プロバイダとKubernetesの管理者の責任になります。Oracle Kubernetes Engine(OKE)のノードでは、Oracle Linuxイメージの強化が必要です。したがってノードがユーザーによってプロビジョニングされたら、それ以降は、Kubernetesの管理者が、このノードで実行されるOracle Linuxイメージに定期的にセキュリティ・パッチを適用していく必要があります。マネージドOKEでは、このノードにCenter for Internet Security(CIS)のKubernetesのベンチマークも使用しています。OSのセキュリティ強化に加え、ノードをプライベート・ネットワークに置き、インターネット経由でアクセスされないようにすることも重要です。必要であれば、クラスタ・ネットワーク外のその他のサービスへのアクセス用にゲートウェイを設定しても良いでしょう。またノード上のネットワーク・ポート・アクセスは、ネットワーク・アクセス・リスト経由で制御する必要があります。ノードへのセキュアシェル(SSH)アクセスを制限することもお勧めです。詳しくは、Oracle Kubernetes Engineのノード・プール・セキュリティに関するドキュメントをご覧ください。

ポッド:ポッドは、ノードで実行され、共有ストレージ/ネットワークを使用する、1つ以上のコンテナの集まりです。デフォルトでは、どのノードでポッドを実行するかに関する制限は付与されていません。クラスタ内でのポッドの通信に関するルールを定義するには、ネットワーク・ポリシーを使用します。ネットワーク・ポリシーを導入するには、ネットワーク・プラグインが必要です。またネットワーク・ポリシーの使用に際しては、これをサポートしているネットワーク・ドライバが必要な場合もあります。Oracle Kubernetes Engineには、クラスタ内のワポッドのノードへの割り当てを制御するポリシーークロードとの間の通信を保護するための オプションが複数あります。ベストなネットワーク・セキュリティ態勢を確立するには、ネットワーク・ポリシー(ポッドレベルの安全なネットワーク通信のため)とセキュリティ・リスト(ホストレベルの安全なネットワーク通信のため)を組み合わせて評価する必要があります。ポッド・セキュリティ・ポリシーでは、たとえばコンテナの特権コンテナとしての実行や、ホスト・ファイル・システムやネットワーク、ポートの使用など、ポッドのランタイム実行プロパティを制御することができます。デフォルトでは、ポッドはクラスタ内のどのノードにもスケジュールできます。Kubernetesには、ポッドのノードへの割り当てを制御するポリシーテイント・ベースのポッドの配置および排除など、ノードへのポッドの割り当てを制御する方法が複数あります。Oracle Kubernetes Engine(OKE)を使用している場合は、こちらのドキュメントの説明にあるとおり、クラスタ向けにポッド・セキュリティ・ポリシーを設定することができます。

 

コンテナのセキュリティ・リスクを排除する

アプリケーションはコンテナ・イメージ(一般的に、Dockerイメージという)としてパッケージされています。コンテナ・イメージ(Dockerイメージ)はコンテナ・レジストリに保存され、そこから抽出されます。またポッド内にてランタイム・コンテナとしてインスタンス化されます。セキュリティは、開発プロセスの最初の時点、つまりアプリケーション用にコンテナ・イメージを構築するためにソース・コードおよびライブラリの作業を実施している時点で、設計原則に組み込まれている必要があります。セキュリティ・プラクティスは、CI/CDツール・チェーンに、またコンテナ・イメージの構築、保存、デプロイのプロセス全体に、導入します。これには、コンテナ・イメージの安全な保存、セキュリティ上の脆弱性を検出するためのイメージのスキャン、コンテナのランタイム・セキュリティの管理などが含まれます。アプリケーションの構築にてサードパーティのライブラリを使用する場合は、DevSecOpsサイクルの一環として、そうしたライブラリの脆弱性スキャンを自動化して実行するのも良いアイデアです。Oracle Kubernetes Engineを使用している場合は、NeuVectorやTwistlockといったオラクルのパートナー・ソリューションを参照することもできます。またDockerイメージおよびコンテナの作成においては、強化されたslimのOSイメージを使用し、アプリケーションを使用するユーザーには、コンテナでのプロセスの実行に必要な最小限のOS権限のみが付与されるようにします。その他にも、ソース・イメージにセキュリティ・アップデートを定期的に適用し、それらをアップデート済みのコンテナとして再度デプロイすることも大切になります。さらに、適切なアクセス・コントロールおよびポリシーを用いて、Oracle Cloud Infrastructure RegistryのようなプライベートなDockerレジストリを使用し、コンテナ・イメージの管理を統制することも重要です。コンテナ・イメージへの署名により、コンテナのコンテンツの信頼性を体系的に維持していくことも、推奨されます。

 

監査、ロギング、モニタリングは必須

監査、ロギング、モニタリングはセキュリティの重要な要素であり、これらによりクラスタのセキュリティ態勢を強化できるため、見過ごすべきではありません。Kubernetes監査ログは、Kubernetes APIサーバーに対して行われた各呼び出しを詳細に記録します。こうした監査ログは、クラスタで起こったことに関する有益な情報になるだけでなく、監査やコンプライアンス、セキュリティの分析にも使用できます。Kubernetes監査のレコードには、一連のアクティビティがすべて記録されたセキュリティ・レコードが含まれているため、異常行動や重要なリソースへのアクセスを検出するのにも役立ちます。したがって不正アクセスなどが発生した場合の分析のため、監査ロギングを有効にし、監査ログを安全なレポジトリに保管することをお勧めします。Kubernetesには、コンテナのアクティビティをセントラル・ロギング・サブシステムに記録するための、クラスタ・ベースのロギング機能もあります。Kubernetesクラスタにある各コンテナの標準出力および標準エラー出力は、各ノードで実行されるFluentdなどのエージェントを使用して、Elasticsearchなどのツールに取り込み、Kibanaにて確認することが可能です。そうすることで、クラスタのコンテナ、ポッド、アプリケーション、サービスなどのコンポーネントをモニタリングすることが可能になります。クラスタのモニタリング、可視化、および追跡には、PrometheusGrafanaJaegerなどのツールを使用できます。

Oracle Cloud Infrastructure Container Engine for Kubernetes(Oracle Kubernetes EngineまたはOKEとも表記される)を使用している場合は、Oracle Cloud Infrastructureセキュリティ・ガイドおよびOracle Kubernetes Engineの安全性確保に関するその他の推奨事項も参照してください。OKEはOracle Cloud Infrastructure(OCI)のIdentity and Access Management(IAM)とも統合されています。IAMは、ネイティブのOCIのユーザー認証機能を使用しており、認証に関する総合的な安全性の向上に寄与します。

Kubernetesクラスタの安全性を今日から強化しましょう。

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.