マネージド Kubernetes の セキュリティをちゃんと考えてみた話し Cloud Native Days Tokyo 2020 乃村 翼 1 

自己紹介 • 乃村 翼 • カスタマーエンジニア@Microsoft(2014 年～) • 詳しくは : http://aka.ms/intropfe • おもな仕事 • Azure に関するいろいろ • アーキテクチャーレビュー • 実装支援 • トレーニング • サポート • 前職 • コンテナ(lxc)を使った自社サービスの 構築/アプリケーション開発 2 tsubasaxZZZ tsubasaxZZZ アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

Kubernetes を使ってサービスを作ろうとしていたある日のこと A君 「Kubernetes を使えばリリースの速度が上がるし、 開発もしやすくなるし、障害にも強くなるんです！！」 上司 「よし、では次のサービスは Kubernetes を基盤にしよう」 A君 「ありがとうございます！ いろいろ便利らしいのでクラウドを使いますね！」 上司 「わかった。ちなみにセキュリティのこともちゃんと考えてね！ 社内のセキュリティポリシーも考慮するように」 A君 「わかりました！(セキュリティって何考えればいいんや。。。)」 3 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

Kubernetes を使ってサービスを作ろうとしていたある日のこと A君 (とりあえず検索っと。。。。”Kubernetes セキュリティ”) A君 (なるほど、4Cが大切なんだな。。ほかには。。。) 4 https://www.cncf.io/blog/2019/01/14/9-kubernetes-security-best-practices-everyone-must-follow/ https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf https://kubernetes.io/docs/concepts/security/overview/ アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

Kubernetes を使ってサービスを作ろうとしていたある日のこと A君 (コンテナセキュリティ、完全に理解した。あ、そういえば社内のセキュリティポリシーってどうなってたっけ) A君 (あれれ、これをマネージドの Kubernetes に当てはめるとどうなるんだ。。 kubectl コマンドって API サーバーと通信しないといけないよな。 これって外部からの通信に当たるのか。。？そこに WAF を挟む？？？ 外部への通信って全部把握することなんてできるのか？？？ そもそも外部と内部って何をもって外部・内部なんだ？ Kubernetes と クラウドの ID 管理、二重管理にならないか？ コンテナのリポジトリ、どこに置けばいいんだ？ストレージ扱いなのか？ アクセス制御ってどうすれば。。。) 5 1. 外部からの通信は必ず WAF を通すこと 2. 外部への通信は必要な通信以外は許可しないこと 3. ウイルス対策ソフトを導入すること 4. ストレージやデータベースは外部からのエンドポイントを持たない(内部からの通信のみ許可する)こと 5. システムにアクセスできるユーザーを限定すること 6. 最新の更新プログラムを適用すること アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

お話しすること マネージド Kubernetes サービスのアーキテクチャーを理解する マネージド Kubernetes サービスのセキュリティを整理する 実装するときの機能を確認する # Azure Kubernetes Service をモデルにします 6 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

Kubernetes のアーキテクチャー 7 kube-apiserver kube-scheduler kube-controller- manager etcd kubelet kube-proxy Container Runtime Pod コントロールプレーン ワーカーノード群 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

マネージド な Kubernetes サービスの管理境界 8 kube-apiserver kube-scheduler kube-controller- manager etcd kubelet kube-proxy Container Runtime Pod クラウドプロバイダーによって管理される領域 ユーザーが管理する領域 コントロールプレーン ワーカーノード群 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

もう一歩踏み込んで AKS の場合 9 kube-apiserver kube-scheduler kube-controller- manager etcd kubelet kube-proxy Container Runtime Pod Azure Resource Manager(Azure CLI/ポータル) デプロイ/管理 Azure によって管理される領域 ユーザーが管理する領域 Azure Active Directory 認証・認可 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

Control Plane もう一歩踏み込んで AKS の場合 Azure Resource Manager Azure のリソースの展開・管理を行う Azure CLI やポータルから操作する AKS コントロールプレーン ワーカーノードとしての VMSS(仮想マシンの かたまり)の展開、ロード バランサーの展開、 kubectl のエンドポイントの提供、Pod の 展開等 Kubernetes 環境の展開・管理 を行う kubectl で操作する 10 Azure Resource Manager 展開/管理 展開/管理 AKS 仮想ネットワーク ロード バランサー VMSS Azure CLI/ポータル kubectl HTTP アクセス Pod Azure Active Directory コンテナ レジストリ アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

AKS を展開した時のポータル画面 11 2 つのリソース グループ ができる AKS のリソースの実態が 展開されるリソース グループ AKS のサービスが 展開されるリソース グループ 展開 クラスター (ワーカーノード) の実態 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

マネージド Kubernetes サービスのセキュリティを整理する 12 Control Plane Azure Resource Manager 展開/管理 展開/管理 AKS 仮想ネットワーク ロード バランサー VMSS Azure CLI/ポータル kubectl HTTP アクセス Pod Azure Active Directory コンテナ レジストリ アーキテクチャーは分かった。ではどのコンポーネントに対して何をすればいいか 3 つのカテゴリで考えてみる • Connectivity • Cluster • Auth アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

マネージド Kubernetes サービスのセキュリティを整理する 13 Control Plane Azure Resource Manager 展開/管理 展開/管理 AKS 仮想ネットワーク ロード バランサー VMSS Azure CLI/ポータル kubectl HTTP アクセス Pod Azure Active Directory コンテナ レジストリ Connectivity クラウド上に Kubernetes を展開する場合、 様々なエンドポイントを持つことになる エンドポイントの存在と管理・制御する方法を意識する <考慮が必要なポイント> • クラウドの管理エンドポイントへの接続 • コントロールプレーンへの接続 • ワーカーノードへの接続(アウトバウンド/インバウンド) • コンテナレジストリ等他のマネージドサービスへの接続 Connectivity アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

AKS の機能 14 Connectivity 考慮が必要なポイント 使える機能 クラウドの管理エンドポイントへの接続 • 条件付きアクセス 条件付きアクセスを使用して Azure 管理へのアクセスを管理する コントロールプレーンへの接続 • プライベート クラスター プライベート Azure Kubernetes Service クラスターを作成する • 許可された IP アドレス範囲 Azure Kubernetes Service (AKS) で許可された IP アドレス範囲を使用して API サーバーへのアクセスをセキュリティで 保護する ワーカーノードへの/からの接続 (アウトバウンド/インバウンド) • アクセス元 IP アドレスの制限(loadBalancerSourceRanges) 受信トラフィックを特定の IP 範囲に制限する • 送信元の 静的 IP アドレスの使用 Azure Kubernetes Service (AKS) ロード バランサーで静的パブリック IP アドレスと DNS ラベルを使用する • 内部ロード バランサー Azure Kubernetes Service (AKS) で内部ロード バランサーを使用する • Azure Firewall Azure Firewall を使用してエグレス トラフィックを制限する コンテナレジストリ等他のマネージドサービス への接続 • プライベート エンドポイント クイック スタート:Azure portal を使用してプライベート エンドポイントを作成する • サービス エンドポイント 仮想ネットワーク サービス エンドポイント アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

条件付きアクセス Azure のポータルへのアクセスに条件を 付けて制御することができる機能 ユーザー・グループやIP アドレス、デバイスの準拠 状態を判断して対象のアプリケーションへのアク セスを許可・拒否できる 15 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

プライベート クラスター 16 Control Plane AKS 仮想ネットワーク ロード バランサー VMSS Pod 仮想ネットワーク プライベート エンドポイント API サーバーへのエンドポイントを 特定の仮想ネットワーク(サブネット) にリンクすることができる プライベート IP アドレスを持つことになるため 外部から kubectl が出来なくなる アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

ワーカーノードへの/からの接続 loadBalancerSourceRanges アクセス元の IP アドレスの範囲を指定 社内アクセスのみに限定する等で利用 静的 IP アドレス ロード バランサーに静的な IP アドレスもしくは パブリック IP アドレスプレフィックスを指定 外部の API 等クラスタ外のサービスで アクセス元の IP 制限をしている場合に利用 17 仮想ネットワーク ロード バランサー VMSS Pod loadBalancerSourceRanges 静的 IP アドレス アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

サービスエンド ポイントとプライベート エンドポイント 18 仮想ネットワーク プライベート エンドポイント コンテナ レジストリ ストレージ アカウント データベース 仮想ネットワーク コンテナ レジストリ ストレージ アカウント データベース ユーザーが管理するリソースの範囲 ユーザーが管理するリソースの範囲 サービスエンド ポイント 特定のサブネットに、指定したサービスをリンクさせ、パブリック IP アドレスでアクセスできる仕組み サービス単位での許可になるため、ユーザーの管理外のサービスへのアクセスは許可してしまう プライベート エンドポイント 特定のサブネットに特定のサービスへのエンドポイントをリンクさせ、プライベート IP アドレスでアクセスできる仕組み <プライベート エンドポイント> <サービス エンドポイント> アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

ここに注意 アウトバウンドのトラフィックを制御するときは慎重に AKS のワーカーノードからは、コントロールプレーンとのトンネル通信、NTP、Kubernetes に関するバイナリのダウンロー ドなど、様々な通信が発生します アウトバウンドのトラフィック制御は原則既定の状態(何も制御しないこと)を前提とし、 どうしても必要になったら検討しましょう 19 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

ここに注意 サービスエンド ポイント vs プライベート エンドポイント マネージドサービスとのプライベート接続は、サービスエンド ポイントもしくはプライベート エンドポイン トを使います サービスエンド ポイントは無料ですが、サービス エンドポイントで許可したサービスは関係ないリソー スに対してもアクセスが可能となります プライベートエンド ポイントを使っていきましょう プライベート クラスターでは使えない機能がある コントロール プレーンの SLA を 99.95 % に引き上げる アップタイム SLAは プライベート クラスターでは使用できません (2020/8 時点) 20 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

ここに注意 プライベートクラスターを使うときは踏み台のことも考える 踏み台のメンテナンス、踏み台へのアクセス制御も忘れずに 条件付きアクセスが本当に必要か考える Azure Active Directory の条件付きアクセスは黒魔術になりがちです MFA を有効にするだけでもほとんどの不正アクセスは防げます 本当に条件付きアクセスが必要か考えましょう 21 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

マネージド Kubernetes サービスのセキュリティを整理する 22 Control Plane Azure Resource Manager 展開/管理 展開/管理 AKS 仮想ネットワーク ロード バランサー VMSS Azure CLI/ポータル kubectl HTTP アクセス Pod Azure Active Directory コンテナ レジストリ Cluster コントロールプレーン、ワーカーノード、Pod の様な Kubernetes クラスタに対する管理・制御を行う クラウドにより管理されるコンポーネントと ユーザーが責任を持つコンポーネントがミックスされる部分 <考慮が必要なポイント> • Kubernetes クラスタのアップグレード戦略 • ワーカーノードのアップデート戦略 • コンテナイメージの管理 • コンテナ実行の制御 • ノードの可用性向上 • データ保存 • セキュリティポリシー • Pod 間通信の制御 Cluster アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

AKS の機能 23 Cluster 考慮が必要なポイント 使える機能 Kubernetes クラスタのアップグレード戦略 • サポートされるバージョン Azure Kubernetes Service (AKS) でサポートされている Kubernetes のバージョン • クラスターアップグレード Azure Kubernetes Service (AKS) クラスターのアップグレード • Ubuntu 18.04 / containerd のテスト・利用 AKS クラスターの構成 ワーカーノードのアップデート戦略 • セキュリティ更新 Azure Kubernetes Service (AKS) の Linux ノードにセキュリティとカーネルの更新を適用します コンテナイメージの管理 • イメージ スキャン Security Center による Azure Container Registry のイメージ スキャン コンテナ実行の制御 • 実行時保護 Security Center のコンテナーのセキュリティ ノードの可用性向上 • クラスターオートスケーラー Azure Kubernetes Service (AKS) でのアプリケーションの需要を満たすようにクラスターを自動的にスケーリング データ保存 • ディスクの暗号化 Azure Kubernetes Service (AKS) でのホストベースの暗号化 (プレビュー) セキュリティ ポリシー • Azure Policy と Open Policy Agent Azure Policy を使用したポッドのセキュリティ保護 (プレビュー) Pod 間通信の制御 • ネットワーク ポリシー Azure Kubernetes Service (AKS) のネットワーク ポリシーを使用したポッド間のトラフィックの保護 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

ここに注意 クラスターアップグレードは計画的に Kubernetes のバージョンは 3 ヶ月おきにバージョンアップされます AKS では、リリースノートとして旧バージョンの非推奨予定日が 30 日前までに公開されます サポートされる n-2 バージョンにバージョンアップをしない場合、自動的にアップグレードされる可能性があります ※以前のドキュメントの記載では Azure が自動的にアップグレードすることはない、となっていたため注意！！ ワーカーノードの更新後は再起動が必要 ワーカーノードに対する OS の更新は自動的に適用されますが、仮想マシンの運用と同様に、OS の更新が適用された場合、再 起動が必要です kured を使って自動的に再起動することも可能です Security Center によるイメージ スキャン プライベート エンドポイントやファイアウォール、サービスエンドポイントを使ってプライベートな構成をしていると Security Center から アクセスすることができないためイメージスキャンができません イメージスキャンのテストをするときは vulnerables/web-dvwa を使うと便利です 24 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

クラスタのアップグレード 構成からコントロールプレーンの アップグレードが可能 コントロールプレーンのアップグレードをしてから、 ノードグループのアップグレードを行う ノードの追加→ドレインを繰り返して 最大サージの割合を超えない台数ずつ アップグレードしていく 25 <コントロールプレーンのアップグレード> <ノードプールのアップグレード> アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

Security Center によるイメージスキャン 26 検出された 脆弱性の一覧 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

ここに注意 Azure Monitor による環境変数の収集の無効化 Azure Monitor for containers を利用すると Kubernetes クラスタに対する監視・情報収集が可能になります 但し、シークレット情報を環境変数に設定している場合、ポー タルから見えてしまいます コンテナの環境変数で AZMON_COLLECT_ENV を "False" に設定するとこの収集を無効化することができます ネットワークポリシーの種類と利用できる環境を把握 AKS で使用できるネットワークポリシーは "Azure ネットワーク ポリシー" と "Calico ネットワーク ポリシー" の2つです Azure ネットワーク ポリシーは Azure サポートによってサポートさ れますが、Calico ネットワーク ポリシーはコミュニティによるサ ポートです kubenet ネットワークプラグインでは、Azure ネットワーク ポリ シーは使用できないため要注意です 27 環境変数が見えている 環境変数が見えない アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

マネージド Kubernetes サービスのセキュリティを整理する 28 Control Plane Azure Resource Manager 展開/管理 展開/管理 AKS 仮想ネットワーク ロード バランサー VMSS Azure CLI/ポータル kubectl HTTP アクセス Pod Azure Active Directory コンテナ レジストリ Auth 認証・認可の仕組みで クラウド基盤へのアクセスを管理する Kubernetes クラスタからアクセスするシークレット情報も 考える <考慮が必要なポイント> • クラウド管理ポータルへのアクセス制御 • Kubernetes クラスタによるクラウドリソースの制御 • Kubernetes クラスタの操作権限(RBAC)の管理 • シークレット情報の格納方法 Auth アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

AKS の機能 29 Auth 考慮が必要なポイント 使える機能 クラウド管理ポータルへのアクセス制 御 • Azure RBAC Azure ロールベースのアクセス制御 (Azure RBAC) とは • Privileged Identity Management Azure AD Privileged Identity Management とは Kubernetes クラスタによるクラウドリ ソースの制御 • Managed ID Azure Kubernetes Service でマネージド ID を使用する Kubernetes クラスタの操作権限 (RBAC)の管理 • Azure AD による認証 AKS マネージド Azure Active Directory 統合 • Azure RBAC による認可 Kubernetes 認可に Azure RBAC を使用する (プレビュー) シークレット情報の格納方法 • CSI ドライバーによる Key Vault のマウント チュートリアル:Kubernetes 上のシークレット ストア CSI ドライバー向けに Azure Key Vault プロバイ ダーを構成して実行する アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

ここに注意 サービス プリンシパルの更新を忘れずに AKS クラスターから Azure リソースにアクセスするために、サービス プリンシパルを 利用する場合、 既定で 1 年の有効期限があります 更新を忘れないようにしましょう。マネージド ID を使うことをおすすめします シークレット情報は Key Vault へ アプリケーションから利用するシークレット情報は Key Vault へ保存することがで きます FlexVolume を使った Key Vault のマウントは非推奨のため、CSI ドライバーを 使用します CSI ドライバーからのマウントはポッド ID を使用し、AzureIdentity のラベルで シークレット情報へアクセスできる Pod を限定します 特権アカウントの定期的な棚卸しを Privileged Identity Management(PIM) を使うと、 承認フローを経た特権昇格、また定期的な棚卸しを自動的に行えます 30 1. 管理者によるロールの割り当て 2. ユーザーによるロールのアクティブ化 3. 管理者による承認 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

参考になるドキュメント Azure Kubernetes Service (AKS) 運用ベースライン https://docs.microsoft.com/ja-jp/azure/architecture/reference- architectures/containers/aks/secure-baseline-aks Azure Kubernetes Service (AKS) でのクラスターのセキュリティとアップグレードに関するベスト プ ラクティス https://docs.microsoft.com/ja-jp/azure/aks/operator-best-practices-cluster-security Azure Kubernetes Service (AKS) の認証と認可のベスト プラクティス https://docs.microsoft.com/ja-jp/azure/aks/operator-best-practices-identity Azure Kubernetes Service (AKS) でのポッドのセキュリティに関するベスト プラクティス https://docs.microsoft.com/ja-jp/azure/aks/developer-best-practices-pod-security Azure Kubernetes Service (AKS) についてよく寄せられる質問 https://docs.microsoft.com/ja-jp/azure/aks/faq 31 アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

お伝えしたかったこと Connectivity / Cluster / Auth のそれぞれの原則と 機能をもとに総合的に設計しましょう 多くの場合セキュアな環境を作ろうとすると 構築工数・運用負荷が上がりがちです 結論としては 「要はバランス」なのですが、 思考停止してしまうと必要以上にセキュアで使いにくい環境、 逆に要件にあっていないリスクのある環境が出来上がります 何をリスクと考えているか？ を常に自問自答しながら設計することを心がけましょう 32 Connectivity Cluster Auth アンケート : https://aka.ms/aks0908 | tsubasaxZZZ 

おわり 33