説明
AppArmor は、Linux コンテナーのファイルアクセスや一部の操作をプロファイルで制限します。対応するノードで適切なプロファイルを使うと、侵害されたプロセスの影響を抑えるのに役立ちます。annotation がないだけで保護がないと断定せず、ランタイムの既定値と実際の適用プロファイルを確認してください。
想定される影響
- 不要なファイル・システムアクセスが許可されると、侵害の影響が拡大する場合があります。
- ノードにプロファイルがない場合やアプリケーションに適合しない場合、コンテナーの起動や必要な機能が失敗することがあります。
対処方法
- AppArmor が有効なノードで RuntimeDefault または確認済みの Localhost プロファイルを使ってください。現在の Kubernetes では、対応するプロバイダー構成を通じて securityContext.appArmorProfile を使用してください。
- Localhost プロファイルは、実行先となり得るすべてのノードに事前に読み込んでください。適用結果と拒否ログを確認し、必要な動作をテストしてください。
例
Kubernetes 1.30 より前の annotation 方式による既存の例です。現在の API では appArmorProfile を使ってください。変更後のローカルプロファイルはノードに事前に用意する必要があり、名前を指定するだけではインストールされません。実際のデプロイには保守されているイメージを使ってください。
変更前
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "terraform-example"
}
spec {
container {
image = "nginx:1.7.9"
name = "example"
}
}
}
変更後
hcl
resource "kubernetes_pod" "pod" {
metadata {
name = "terraform-example"
annotations = {
"container.apparmor.security.beta.kubernetes.io/example" = "localhost/k8s-apparmor-example-allow-write"
}
}
spec {
container {
image = "nginx:1.7.9"
name = "example"
}
}
}
補足:
- 変更前: 明示的な AppArmor annotation はありません。ランタイムの実際の既定プロファイルを確認する必要があります。
- 変更後: コンテナー example に、事前に読み込んだローカルプロファイルを要求します。ルールの内容と対応状況も確認してください。