GCP上での解決策もご紹介！Kubernetes運用におけるセキュリティ対策の考え方

Googleが開催するイベントのGoogle Cloud Dayでは、Google Cloudの最新ソリューションを学ぶことができます。今年はCOVID-19の影響もあり、リモートでの開催となりました。この記事では数あるセッションの中から、Kubernetes運用におけるセキュリティ対策に関連するセッションを取り上げ、GKEやAnthosにおけるセキュリティの考え方についてご紹介します。

この記事で紹介するセッション

この記事ではGoogle Cloud Dayで公開された下記のセッションを参考に、GKEやAnthosを活用したKubernetes運用におけるセキュリティ対策についてご紹介します。

Kubernetes 運用における Security Policy 適用 with Anthos

取り上げる主な Google Cloud 製品 / サービスは以下になります。

• Kubernetes Engine (GKE)
• Anthos
• Cloud Build

Kubernetes環境におけるセキュリティ

アプリケーションのコンテナ化により、開発のアジリティを向上させたいと考える方は多いと思います。しかし、Kubernetes環境の構築や運用を0から自分自身で行うのは負荷が大きいため、採用のハードルは高いのが実情です。そこでよく利用されるのが、クラウドベンダーが提供するマネージドのKubernetesサービスです。GCP(Google Cloud Platform)ではGKE(Google Kubernetes Engine)というサービスを提供しており、高いスケール性を持ちながら運用負荷を最小限に抑えることができます。

GKEを利用する場合、注意しなければならないのはセキュリティです。従来型のアプリケーションと考え方が異なるため、セキュリティが担保できているかどうかを判断することが難しく、様々な観点からの考慮が必要です。

Anthosのセキュリティ機能

GCPでは、Anthosというハイブリッドやマルチクラウド環境の運用管理プラットフォームを提供しています。AnthosではGKEをベースに、アプリケーションをモダナイズするための様々なサービスで構築されています。ここではそのセキュリティ機能にフォーカスし、コンテナアプリケーションのセキュリティについて考えていきます。

アプリケーションデプロイのプロセス

まずは、アプリケーションをデプロイするプロセスを簡単に確認します。

Step 1: コンテナイメージの作成

まずはアプリケーションをコンテナ化するために、Dockerfileを作成し、イメージをGoogle Container Registryに登録します。

Step 2: マニフェストファイルの作成

アプリケーションを稼働させるために、Kubernetes manifestのDeployment及びServiceを作成します。先程登録したイメージをDeploymentの中のTemplateに指定します。

Step 3: ビルドしたイメージをGKEにデプロイ

マニフェストファイルを適用するコマンド(kubectl apply等)を利用し、ビルドしたイメージをGKEにデプロイします。

この3ステップでアプリケーションのデプロイは完了です。

デプロイしたクラスタ内の状態

上記のプロセスでデプロイしたクラスタの状態を確認します。まず、Cluster IPが自動的に払い出され、内部サービス間の通信が可能です。namespaceが複数ある場合には、その通信にも制限はありません。また、kubernetesのCPUやメモリなどの各リソース、及びPod数やQuotaに上限は設定されていません。

GCPプロダクトとの連携については、クラスタに紐づくGoogleサービスアカウントが持つ権限で制御されています。そのため、クラスタ内では同じ権限が付与されることになり、Podやnamespace単位でのきめ細かい権限制御は行われていないことになります。

コンテナイメージの脆弱性

ここからは、アプリケーションをデプロイするプロセスにおけるそれぞれの段階におけるセキュリティ上の課題点、及びその解決策についてご紹介します。

まずはコンテナイメージの作成時におけるセキュリティ上の課題点です。最も注意しなければならないのは、イメージの脆弱性です。具体的には、下記の観点で対策を実施する必要があります。

• ベースイメージにそもそも脆弱性がないか
• ビルドして作成されたイメージに脆弱性はないか
• 今後も継続的に脆弱性がない状態であることを保証できるか

ベースイメージの考慮

それぞれの観点におけるセキュリティ対策を考慮していきます。まず、ベースイメージの脆弱性に関して、Googleではマネージドベースイメージを提供しています。このイメージでは最新のセキュリティパッチが自動適用されるため、ユーザーは常に安全な状態のイメージを利用することができます。OSのディストリビューションについてはこちらで確認することが可能です。

イメージ脆弱性スキャン

ビルドして作成したイメージに対しては、Google Container Registory上でイメージ脆弱性スキャンを行うことができます。下記の5種類のCVE(Common Vulnerabilities and Exposures)データを元に、コンテナイメージの脆弱性の重大度を5段階で判定します。

• Debian
• Ubuntu
• Alpine
• Red Hat Enterprise and CentOS
• National Vulnerability Database

脆弱性のあるイメージをデプロイさせない仕組み

脆弱性を検知した場合でも、ビルドが成功していれば、その脆弱性のあるイメージを定義したマニフェストをGKEに展開してしまう可能性があります。そこで、脆弱性スキャンの結果、問題がないと判断されたコンテナイメージのみをGKEにデプロイできるように制限をかける仕組みが必要となります。

Anthosでは、Binary Authorizationという機能を提供しています。この機能を利用することで、信頼できるコンテナイメージのみがGKEにデプロイされることを保証することができます。イメージのデプロイ時に署名を確認し、ポリシーに違反していた場合にはデプロイが実施されることはありません。

また、署名の追加処理はイメージ脆弱性スキャンとCloudBuild、及びCloud KMSを連携することで自動化することが可能です。影響度の高い脆弱性がないイメージに対して署名を作成します。

セキュアなソフトウェアサプライチェーンの実現

上記の対策を行うことで、アプリケーションのデプロイ時に懸念となる脆弱性をできるだけ排除し、安全なイメージをデプロイすることができるようになります。また、脆弱性は時間経過とともに新たな手口が発見されることも多いため、ある一時点で対策を実施するだけではなく、最新の情報を元に継続的に実施する必要があります。

デプロイ後のネットワークと権限

次に、デプロイが完了した後のセキュリティ上の課題点を考えていきます。前述した通り、各サービス間の通信の制限やGCPプロダクトに対する権限設定を適切に行い、必要最小限のアクセスのみを許可するように設計する必要があります。

ASMによるL7トラフィックの制御

まずは通信の認証、及び認可を設定することで、L7レベルでのトラフィックの制御を行います。Anthosでは、ASM(Anthos Service Mesh)というフルマネージドのサービスメッシュを提供しています。ASMを活用することで、認証、認可の機能を実装することが可能です。

トラフィックの認証

ASMによるL7トラフィックの認証では、mTLSによる相互認証が行われます。サイドカープロキシーとしてEnvoyを稼働させ、各アプリケーションはEnvoyを経由して通信を行います。mTLSでは、サーバー クライアント間の通信を相互に認証するため、接続先だけでなく、接続元の信頼性も保証することが可能です。

トラフィックの認可

また、トラフィックに対してルールを指定してコントロールすることでサービス間の予期しないリクエストを避けることができます。

上図ではfoo-saサービスアカウントからbar namespaceに対する通信制御を定義しています。infoから始まるパスに対するGETリクエスト、及びdataで終わるパスに対するPOSTリクエストのみが許可されており、それ以外の通信は全て拒否されます。

Network Policyの活用によるPodレベルのファイアウォール

次に、Podレベルでのトラフィック制御を考慮します。選択したPod間でのみ通信を許可するL3/L4レベルでのトラフィックルールを定義します。

上図では、app: bar-appというラベルの付いたPodはapp: foo-appというラベルの付いたPodからのアクセスのみを受け付けます。

RBACの適用によるアクセス制限

また、通信の制御に加えて、権限にも考慮が必要です。RBAC(Role-Based Access Control)を適用することでロールベースのアクセス制御を実現することが可能です。Kubernetesのロールをサービスアカウント等に対して紐付け、namespaceやクラスタ単位で権限を制御します。

上図ではPodに対してGET、WATCH、LISTのリクエストが許可されています。

Workload IdentityとGCPの権限

GCPに対する権限を最小化することを考えます。GKEでは、Workload Identityという機能を提供しています。この機能を利用することで、KSA(Kubernetes Service Account)をGSA(Google Service Account)として認証することが可能となり、開発者はKSAのみを意識して権限設定をおこなうことでGCPプロダクトへのアクセスを管理することができます。

特権コンテナの制御

サービス間のアクセス制御だけでなく、プロセス間のアクセス制御も必要です。Podやコンテナの定義によっては、特権コンテナと呼ばれる、ホストと同等の権限を持ったコンテナを実行することができます。様々なユースケースで利用されますが、セキュリティ面から見ると特権コンテナの実行は決して安全ではなく、攻撃の踏み台とされた場合にはネットワークスタックやデバイス等、広範囲に渡ってアクセスを許してしまいます。

上記をコントロールするために、PodSecurityPolicyを利用することができます。PodSecurityPolicyでは特権モードでのコンテナの利用やroot権限でのコンテナの実行を禁止することができます。

デプロイ後のアクセス権限の最小化

イメージがデプロイされた後は、サービス間のアクセス権限を最小にするだけではなく、GCPプロダクトに対する利用権限や、コンテナ自体の権限も含めた考慮が必要となります。

ポリシー適用時の課題点

最後に、マニフェストファイルのポリシーをクラスタに反映する場合に注意すべきセキュリティ上の考慮点についてご紹介します。適切にポリシーが定義できていたとしても、それがデプロイするべき全てのクラスタへ反映できていることを保証する必要があります。

ACMによるポリシー管理の仕組み

GCPでは、ACM(Anthos Config Management)というサービスを提供しています。ACMはハイブリッド、マルチクラウド環境でポリシー管理を容易に行うことができるサービスであり、ポリシー設定を複数のクラスタ間に自動で同期することや、適用前のポリシーの監査を行うことが可能です。

Config Sync

ACMのConfig Syncという機能では、単一のGitリポジトリによるコミットにより、複数のクラスタに対してクラスタの設定変更を自動で適用することができます。この仕組みにより、常に最新のポリシーがクラスタに適用されていることが保証されます。

Policy Controller

ACMではPolicy Controllerという機能が利用できます。クラスタに制約を設定することで、コンプライアンスを強化することが可能です。また、適用前のポリシーの監査をすることができます。

上図では、namespaceにgeoラベルを必須とする制約を設定しています。この制約に則っていないマニフェストファイルをデプロイしようとするとエラーが発生します。

継続的なポリシーの自動適用

上記のACMの機能を利用することで、適切なポリシーを全てのクラスタに継続的に自動適用する事が可能です。セキュリティ管理のチームが全クラスタにポリシーを適用することで、ディベロッパーのチームが適用するマニフェストを一律でコントロールするといった運用を実現することができます。

まとめ

この記事では、コンテナイメージを作成してから実行するまでの様々なプロセスにけるセキュリティの考慮事項を説明し、GCP上での解決策をご紹介しました。イメージの脆弱性や各種権限設定、ポリシーの適用方法など、考慮事項は多岐にわたりますが、GKEやAnthosといったGCPのプラットフォームを利用することで、より簡単にセキュアなKubernetes環境を構築することが可能となります。

弊社トップゲートでは、Google Cloud (GCP） 利用料3%OFFや支払代行手数料無料、請求書払い可能などGoogle Cloud (GCP）をお得に便利に利用できます。さらに専門的な知見を活かし、

• Google Cloud (GCP）支払い代行
• システム構築からアプリケーション開発
• Google Cloud (GCP）運用サポート
• Google Cloud (GCP）に関する技術サポート、コンサルティング

など幅広くあなたのビジネスを加速させるためにサポートをワンストップで対応することが可能です。

Google Workspace（旧G Suite）に関しても、実績に裏付けられた技術力やさまざまな導入支援実績があります。あなたの状況に最適な利用方法の提案から運用のサポートまでのあなたに寄り添ったサポートを実現します！

Google Cloud (GCP）、またはGoogle Workspace（旧G Suite）の導入をご検討をされている方はお気軽にお問い合わせください。

お問合せはこちら


メール登録者数3万件！TOPGATE MAGAZINE大好評配信中！
Google Cloud（GCP）、Google Workspace（旧G Suite） 、TOPGATEの最新情報が満載！

メルマガ登録はこちら