説明
AppArmor は、Linux コンテナーによるファイルやネットワークなどのシステムリソースへのアクセスを制限します。意図したプロファイルが適用されなければ、侵害されたアプリケーションのアクセス範囲が広がる場合があります。明示的な設定がないだけで保護が全くないとは断定できず、ノードの対応状況とランタイムの既定プロファイルを確認する必要があります。
想定される影響
- 不要なシステムアクセスが許可されると、侵害の影響が大きくなるおそれがあります。
- 無効なプロファイル名や非対応ノードにより、コンテナーが起動できない場合があります。
対処方法
- 対応する API では securityContext.appArmorProfile に RuntimeDefault または検証済みの Localhost プロファイルを指定してください。過去の annotation を使う場合は Kubernetes バージョンの対応状況を確認してください。
- ノードで AppArmor が有効なことを確認し、カスタムプロファイルは実行先となるすべてのノードに事前ロードしてください。実際の適用状態と、アプリケーションに必要な動作を試してください。
例
過去の AppArmor annotation 形式を比較します。新しい構成では、導入バージョンが対応する appArmorProfile フィールドを使ってください。
変更前
yaml
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
container.apparmor.security.beta.kubernetes.io/hello: dummy
spec:
containers:
- name: hello
image: busybox
command: ["sh", "-c", "sleep 1h"]
dummy は過去の形式で有効なプロファイル指定ではありません。保護なしで正常起動すると仮定せず、起動が拒否されるか確認する必要があります。
変更後
yaml
apiVersion: v1
kind: Pod
metadata:
name: hello-apparmor
annotations:
container.apparmor.security.beta.kubernetes.io/hello: runtime/default
spec:
containers:
- name: hello
image: busybox
command: ["sh", "-c", "sleep 1h"]
過去の形式でランタイムの既定プロファイルを要求します。ノードの AppArmor 対応と実際の適用状態も確認する必要があります。