ホーム
お役立ち
Google Service
Kubernetes を安全に利用するためには？ GKE と Anthos を活用したセキュリティ対策を徹底解説！

Kubernetes を安全に利用するためには？ GKE と Anthos を活用したセキュリティ対策を徹底解説！

Anthos
GCP
GKE
Kubernetes
セキュリティ対策

公開年月日: 2023.05.31

更新年月日: 2024.09.26

Kubernetes を安全に利用するためには？ GKE と Anthos を活用したセキュリティ対策を徹底解説！

近年、クラウドの普及とともにコンテナ技術の重要性が高まっています。コンテナを活用することで開発環境の構築を効率化でき、スピード感のある開発が可能になります。そして、コンテナオーケストレーションシステム（コンテナの運用・開発を効率化するためのシステム）として注目を集めているのが Kubernetes です。

本記事では、 Google が提供する「 Google Kubernetes Engine （GKE）」と「 Anthos 」という2つのサービスに注目し、 Kubernetes におけるセキュリティの考え方やセキュリティ対策のベストプラクティスの詳細をご紹介します。

本記事で使用している画像の出展元は、 Google Cloud Japan の資料です。

Kubernetes とは？

まずは Kubernetes という言葉を正しく理解しておきましょう。

Kubernetes とは、コンテナの運用管理および自動化を実現するためのオープンソースソフトウェア（OSS）であり、一般的には「コンテナオーケストレーションシステム（ツール）」と呼ばれています。 OSS とは Linux に代表される無料で使えるオープンソースのことです。

コンテナにはアプリケーションを実行する機能が備わっていますが、コンテナの管理や別サーバーとの連携はできません。 Kubernetes はこれらの課題を解決するためのツールです。

例えば、2つ以上のコンテナを運用する場合、ネットワークやストレージなどの連携管理が必要になりますが、 Kubernetes はこれらの管理を行うことができ、仮にコンテナやアプリケーションにトラブルが発生したときでも慌てることなく運用を継続することが可能です。

Kubernetes に関心のある方は以下の記事が参考になります。

Kubernetes とは？概要、機能、メリット、活用事例まで徹底解説！

Google Kubernetes Engine （GKE）とは？

Google Kubernetes Engine （以下 GKE ）は Google Cloud （GCP）上で提供されている Kubernetes のマネージドサービスです。マスターノードは GKE が管理を行うため、ユーザー側は管理の必要がありません。

さらに、ロードバランサーとの連携によるネットワークトラフィックの負荷分散やロギング・モニタリングなど、利用者にとって嬉しいポイントが数多く存在します。

このように、 GKE は自社の構築や運用におけるワークロードの負荷を軽減しながら Kubernetes 環境としてクラウド上で利用できるコンテナのプラットフォームとなっています。 Google Cloud （GCP）の各種機能とも容易に連携でき、デフォルトの状態で様々なことを実現できる点も GKE が人気を集めている理由の一つと言えるでしょう。

また、 2021 年 2月に GKE の新しいモードである GKE Autopilot がリリースされました。

GKE Autopilot の実装に伴い、従来の GKE は「 GKE Standard 」と名称が変更されています。基本的な仕組みは GKE Standard と同じですが、いくつか GKE Autopilot ならではの特徴が存在します。

例えば、ノードが完全マネージドで提供されている点が挙げられます。そのため、ノードを自社で運用する必要はなく、企業は Kubernetes 利用などの生産性の高い業務に集中できます。ノード管理の仕組みとしては、 Cluster autoscaler （CA）と Node auto provisioning （NAP）を使い、ノードを動的に作成、削除しています。

また、 GKE Autopilot では、 Pod 単位で 99.9% （ Monthly Uptime Percentage ）　の SLO （ Service Level Objective ：サービスレベル目標）が設定されています。対象となる条件は「2つ以上のゾーンに Pod が配置されていること」であり、 Pod とは別に Control Plane には 99.95% のSLO が設定されています。

GKE や GKE Autopilot に関心のある方は以下の記事がオススメです。

Google Kubernetes Engine （ GKE ）の2021最新機能を一挙紹介！さらに便利で使いやすくアップデート？

Anthos とは？

Anthos とは、 Google が提供している「アプリケーションを管理するためのプラットフォーム」です。ハイブリッドクラウド環境やマルチクラウド環境に対応しており、サービスメッシュやサーバーレス、 GitOps 、コンテナセキュリティなど、モダナイゼーションに有用な機能が数多く提供されています。

Anthos のコアとなるのはマネージドな Kubernetes クラスタであり、 Google Cloud （GCP）だけではなく、オンプレミスやマルチクラウド上で動作させることができるマネージドな Kubernetes クラスタを提供しています。

さらに、サーバレス、セキュリティ管理、ハイブリッド負荷分散、マーケットプレイス、サービスメッシュ、設定・ポリシー管理など、エンタープライズで求められる様々な機能群をパッケージとして内包している点も Anthos の大きな特徴です。

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

各サービスをご紹介したところで、次は Kubernetes 環境におけるセキュリティについて考えてみましょう。

アプリケーションのコンテナ化により、開発のアジリティを向上させたいと考える方は多いと思います。しかし、 Kubernetes 環境の構築や運用を自分自身ですべて行うのは負荷が大きいため、採用のハードルは高いのが実情です。

そこで、よく使用されるのがクラウドベンダーが提供するマネージドの Kubernetes サービスです。前述した通り、 Google Cloud （GCP）には GKE が搭載されており、高いスケール性を持ちながら運用負荷を最小限に抑えることができます。

ただし、 GKE を利用する場合に注意すべき点が自社のデータを保護するためのセキュリティです。従来型のアプリケーションとは考え方が異なるため、安全性が担保できているかどうかを判断することが難しく、様々な観点からセキュリティ構成などを考慮することが必要になります。

GKE では、 Google Cloud （GCP）のサービスアカウントや IAM を連携して権限を制御するなど、セキュリティを強化するための機能が多く実装されています。これらを活用することで、安全な環境で Kubernetes を利用可能になります。

また、 Anthos Service Mesh の Binary Authorization を使うことで、信頼できるコンテナイメージのみを GKE にデプロイするなど、より安全性の高い仕組みを構成することができます。このように、 Kubernetes 環境におけるセキュリティを担保する上では、 GKE や Anthos のセキュリティ機能が重要な意味を持ちます。

ここからは、 Kubernetes 環境の安全性を高めるための具体的な方法について解説します。

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

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

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

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

コンテナイメージの作成

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

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

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

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

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

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

以上でアプリケーションのデプロイは完了です。

4.デプロイしたクラスタ内の状態確認

最後に、上記プロセスでデプロイしたクラスタの状態を確認します。

まず、 Cluster IP は自動的に払い出され、内部サービス間の通信が可能となっています。また、 namespace が複数ある場合にはその通信にも制限はなく、 kubernetes の CPU やメモリなどの各リソースおよび Pod 数、 Quota に上限は設定されていません。

なお、 Google Cloud （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 Service Mesh の Binary Authorization を利用することで、信頼できるコンテナイメージのみが GKE にデプロイされることを保証できます。なお、イメージのデプロイ時に署名を確認し、ポリシーに違反していた場合にはデプロイが実行されることはありません。

Binary Authorizationの説明

また、署名の追加処理はイメージ脆弱性スキャンと Cloud Build および Cloud Key Management Service 【 Cloud KMS 】を連携することで自動化できます。この時、影響度の高い脆弱性がないイメージに対して署名を作成します。

影響度の高い脆弱性がないイメージに対して署名を作成

ここまでご紹介したセキュリティ対策を実施することで、アプリケーションのデプロイ時に懸念となる脆弱性をできるだけ排除し、ランタイム環境においても安全なイメージをデプロイすることが可能になります。ただし、脆弱性は時間経過とともに新たな手口が発見されることも多いため、ある一時点で対策を講じるだけではなく、最新の情報を基にして継続的に実施する必要があります。

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

デプロイ後のセキュリティ対策

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

Anthos Service Mesh による L 7 トラフィックの制御

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

Anthos Service Meshの概要

トラフィックの認証

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

ASMによるL7トラフィックの認証

トラフィックの認可

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

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

L7トラフィックの認可

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

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

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

Network Policyの適用

Role-Based Access Control の適用によるアクセス制限

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

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

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

Workload IdentityとGoogle Cloud （GCP）の権限

次は Google Cloud （GCP）に対する権限を最小化することを考えます。 GKE では Workload Identity という機能を提供しています。

この機能を利用することで Kubernetes Service Account （KSA）を Google Service Account （GSA）として認証できるようになり、開発者は KSA のみを意識して権限設定を行うことで Google Cloud （GCP）のプロダクトへのアクセスを管理可能になります。

Workload IdentityとGCPの権限

特権コンテナの制御

サービス間のアクセス制御だけでなく、プロセス間のアクセス制御も必要です。 Pod やコンテナの定義によっては、特権コンテナと呼ばれるホストと同等の権限を持ったコンテナを実行することができます。

特権コンテナは様々なユースケースで利用されますが、セキュリティ面から見ると特権コンテナの実行は決して安全ではなく、攻撃の踏み台とされた場合にはネットワークスタックやデバイスなど、広範囲に渡ってアクセスを許してしまいます。

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

PodSecurityPolicyの適用

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

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

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

ポリシー適用時のセキュリティ対策

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

Anthos Config Management によるポリシー管理の仕組み

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

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

Config Sync

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

以下、 Config Sync のコンポーネントを図で示します。

Config Sync の仕組み

Policy Controller

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

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

Policy Controllerによりポリシールール適用

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

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

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