はじめに
Azureコンテナソリューショングループ）土居です。
我々の部署ではAzureにフォーカスをあてクラウドネイティブ関連の技術を追求しお客様をサポートしていきます。
その一環としてAzureに関して日々ブログで技術紹介していきますので宜しくお願いします。
今回はAKSで利用できるAAD Pod Identityについて紹介していきます。
Kubernetesにおけるシークレットの格納先
Kubernetes上で稼働させるPodでシークレット（ここではDB接続文字列やAPIキーなど）を利用する方法として大別して以下の4種類が考えられます。
- アプリケーションのソースコード内にハードコーディングする
- Podのマニフェストファイル内に記述する
- KubernetesのSecretを利用する
- 外部のシークレット管理に特化したサービス（AzureではKey Vault）を利用する
1および2は運用やセキュリティ上の観点より利用されるケースはほとんどなく、3か4のどちらかを本番環境で利用する事になります。
SecretはKubernetes上の標準リソースのため扱いやすく、管理もKubernetes内で一元化されるため、こちらを利用したほうが分かりやすいです。
しかし、Secretはkubectlによる参照、マニフェストファイル上のシークレット情報はbase64にてエンコードされているだけで暗号化されているわけではないので、安全性を確保しようとすると一工夫が必要になります。前者はRBACによるkubectl権限の制限、後者はkubesec,SealedSecretなどを利用して暗号化する必要があります。
大規模で複数人がクラスターを共同で利用しているような場合では、上記の運用ルールが形骸化されないように運用責任者が管理していく必要があります。
シークレットを事前にKey Vault内に格納しておけば、マニフェストファイル上にシークレットの情報を記載する必要がなくなり、Key Vault自体のきめ細やかなアクセス管理が利用できるため、Secretの時のような管理負荷が軽減されます。
さらに、AKSではSecretで利用されるetcdもAzure標準の仕組みで暗号化されていますが、Key VaultではHSMというハードレベルの強固な規格により保護されています。システムに求められる法令要件によってはこちらの選択が望ましいケースもあります。
AAD Pod Identity とは
AAD Pod Identityをどういったものか完結に表すと以下の表現になります。
AKS上で動くアプリケーション（Pod）からシークレットを必要とせずAzureリソース上に安全にアクセスできるようにするためのマネージドIDを用いた仕組み
AAD Pod IdentityはPodとマネージドIDとの連携にBindingを利用します。 そして、Bindingで割り当てられたマネージドIDを利用して認証を行う際、トラフィックはNMIに転送されます。 NMIはPodと関連付けられたマネージドIDのアクセストークンを要求し、発行されたアクセストークンをPodに返却します。 Podはこのアクセストークンを利用してAzureリソースへシークレットを必要とせずアクセスが可能です。 SecretやKey Vaultにシークレットを格納するよりも簡単でセキュアです。
しかし、マネージドIDを利用した仕組みのため、現状以下のような制限があるため注意が必要です、
- Azure上のリソースにしか利用できない
- マネージドID認証に対応したリソースしか利用できない
Azure上のリソースしか利用できないため、Azure外のリソースへのアクセスには従来通りのSecretまたはKey Vaultを利用してシークレットによるアクセスが必要になります。
また、マネージドID認証に対応しているリソースは少ないです。少しずつ増えていますが、対応していないAzureリソースにAAD Pod Identityを使ってアクセスする場合は、シークレット情報をKey Vaultに格納しておき、AAD Pod Identityを使ってパスワードレスでKey Vaultに一旦アクセスしシークレット情報を抜き取ってくるような二段階処理が必要です。
AAD Pod Identityインストール
AAD Pod Identityのインストール情報は公式にいくつか方法が記載されていますのでそちらを参考にして下さい。
インストールの前提として以下の2つを理解して下さい。
- インストール方法に手動（Helm）と自動（AKSアドオンプレビュー）の2種類がある
- ネットワークプラグインはAzure CNIかCalicoが推奨
インストール方法については、どちらの方法でのインストール手順を記載しているのか理解した上で進めて下さい。AAD Pod Identityの既定では、AKSクラスター上でNMIとMICの2種類のコンポーネントが動作します。しかし、AKSアドオンでインストールするとManaged Modeで動作し、MICコンポーネントは使用されません。
ネットワークプラグインについては、ARPスプーフィングによるPodなりすましを防ぐためにkubenetは推奨されていません。 どうしてもKubenetでAAD Pod Identityを利用する場合はゲートキーパーのインストール等で上記を防ぐような方法が有効です。
最後に
AAD Pod Identityはうまく使いこなせれば管理者を悩ませるシークレット管理から解放することができます。
マネージドID認証に対応したリソースが少なく利用シーンが限定的になりがちのため、Key Vaultにシークレットを格納し、Secret Store CSI Driver等を使ったAAD Pod Identity + Key Vaultの連携パターンで対応リソースを増やすのが現状での利用パターンとなります。Key VaultへのアクセスにサービスプリンシパルでなくマネージドIDが利用できるため、シークレットのライフサイクルを意識する必要もなくなるのが利点です。
しかし、内部で動作している仕組みは少し煩雑となり依存リソースも多くなるため、可用性の観点やトラブルシュートの複雑度は増しますのでよく見極めながら利用を検討してもらえると良いと思います。
