第19章 Kubernetesでアプリケーションを保護する Kubernetesでアプリケーションをセキュリティで保護する
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
ワークロードを実行するためのセキュアなプラットフォームを提供することは、Kubernetesが本番環境で広く利用されるために不可欠だ。 ありがたいことに、Kubernetesにはセキュアな運用環境を構築できる、セキュリティに特化したさまざまなAPIが同梱されている。課題は、多くの異なるセキュリティAPIがあり、それらを使用するには宣言的にオプトインしなければならないことだ。これらのセキュリティに特化したAPIを使用することは、面倒で複雑な場合があり、希望のセキュリティ目標を達成することを難しくする。
KubernetesでPodのセキュリティを確保する際には、多層防御と最小権限の原則という2つの概念を理解することが重要だ。多層防御とは、Kubernetesを含むコンピューティング・システム全体で多層のセキュリティ制御を使用する概念だ。最小権限の原則とは、ワークロードが演算子として必要なリソースだけにアクセスできるようにすることだ。これら2つの概念は、目的ではなく、変化し続けるコンピューティング・システムの状況に常に適用されるものだ。
この章では、Podレベルでワークロードのセキュリティを確保するためにインクリメント的に適用できる、セキュリティに特化したKubernetes APIを取り上げる。
SecurityContextを理解する
SecurityContextは、Podとコンテナ仕様の両方のレベルで適用できる、セキュリティに焦点を当てたすべてのフィールドの集合体である。 以下は、SecurityContextがカバーするセキュリティ制御の例である:
-
ユーザの権限とアクセス制御(ユーザIDとグループIDのセットなど)
-
読み取り専用のルートファイルシステム
-
特権の昇格を許可する
-
Seccomp、AppArmor、SELinuxのプロファイルとラベルの代入
-
特権または非特権で実行する
例19-1で定義したSecurityContextを持つPodの例を見てみよう。
例 19-1. kuard-pod-securitycontext.yaml
apiVersion:v1kind:Podmetadata:name:kuardspec:securityContext:runAsNonRoot:truerunAsUser:1000runAsGroup:3000fsGroup:2000containers:-image:gcr.io/kuar-demo/kuard-amd64:bluename:kuardsecurityContext:allowPrivilegeEscalation:falsereadOnlyRootFilesystem:trueprivileged:falseports:-containerPort:8080name:httpprotocol:TCP
この例では、Podレベルとコンテナレベルの両方にSecurityContextがあることがわかる。 セキュリティ制御の多くは、これら両方のレベルで適用できる。両方で適用する場合は、コンテナレベルの設定が優先される。 ...