チェック ID | チェック項目 | 説明とセキュリティリスク | 修正 |
hostNetworkSet | コンテナがホストネットワーク名前空間を共有することを防止 | ワークロードの Pod の spec に hostNetwork: true が設定されているかどうかを確認します。この設定が有効になっている場合、コンテナはホストのネットワーク名前空間にアクセスできるため、Pod 内からのネットワーク攻撃やデータスニッフィングのリスクが生じます。 | Pod spec を変更して hostNetwork フィールドを削除します。 例： labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
|
hostIPCSet | コンテナがホスト IPC 名前空間を共有することを防止 | ワークロードの Pod spec に hostIPC: true が設定されているかを確認します。この設定が有効になっていると、コンテナがホストの IPC 名前空間にアクセスできるようになり、ホスト上の他のプロセスへの攻撃やデータのスニッフィングが可能になります。 | Pod の spec を変更して、hostIPC フィールドを削除します。 例： labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
|
hostPIDSet | コンテナがホスト PID 名前空間を共有することを防止 | ワークロードの Pod spec に hostPID: true が設定されているかどうかを確認します。この設定が有効な場合、コンテナはホストのプロセス ID (PID) 名前空間にアクセスできるようになり、ホスト上の他のプロセスを攻撃したり、データを収集したりすることが可能になります。 | Pod の spec を修正して、hostPID フィールドを削除します。 例： labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
|
hostPortSet | コンテナプロセスがノードポートをリッスンすることを防止 | ワークロードの Pod spec でhostPortが設定されているかどうかを確認します。コンテナポートがホストノードのポートにマッピングされている場合、ホストポートを占有し、意図しない送信元からのリクエストを受信するおそれがあります。 | Pod spec を変更して、hostPort フィールドを削除します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
|
runAsRootAllowed | コンテナが root ユーザーとして実行されることを防止 | ワークロードの Pod spec に runAsNonRoot: true が設定されているかどうかを確認します。この設定がされていない場合、コンテナはデフォルトで root ユーザーとして実行されます。これにより、悪意のあるプロセスがアプリケーション、ホスト、またはクラスター全体を侵害するリスクが生じます。 | Pod の spec を変更して runAsNonRoot: true を追加します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
securityContext:
runAsNonRoot: true
|
runAsPrivileged | コンテナが特権モードで実行されることを防止 | ワークロードの Pod spec に privileged: true が設定されているかどうかを確認します。この設定が有効になっている場合、コンテナはホストへの root アクセスが可能になります。これにより、悪意のあるプロセスがお客様のアプリケーション、ホスト、またはクラスター全体を侵害する深刻なリスクが生じます。 | Pod の spec を変更して、privileged フィールドを削除します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
securityContext: {}
|
privilegeEscalationAllowed | コンテナ内での権限昇格を防止 | ワークロードの Pod spec に allowPrivilegeEscalation: false が設定されているかどうかをチェックします。この設定がされていない場合、コンテナ内の子プロセスが親プロセスよりも多くの権限を取得できるため、権限昇格攻撃のリスクが生じます。 | Pod の spec を変更して、allowPrivilegeEscalation: false フィールドを追加します。 例： ports:
- containerPort: 80
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsNonRoot: true
volumeMounts:
|
capabilitiesAdded | 不要な Linux ケーパビリティの削除 | ワークロードの Pod の spec にある capabilities フィールドをチェックし、SYS_ADMIN、NET_ADMIN、または ALL などの特権レベルの高い Linux ケーパビリティが許可されているかを確認します。これらのケーパビリティが付与されている場合、悪意のあるプロセスがそれらを使用してアプリケーション、コンポーネント、またはクラスターを侵害するおそれがあります。 | Pod スペックを修正して、必要な Linux ケーパビリティのみを追加し、その他はすべて削除します。 追加の Linux ケーパビリティが不要な場合は、すべて削除します。例： spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
securityContext:
capabilities:
drop:
- ALL
特定のケーパビリティが必要な場合は、必要なものだけを追加し、その他はすべて削除します。例： spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
securityContext:
capabilities:
add:
- CHOWN
drop:
- ALL
|
notReadOnlyRootFilesystem | コンテナに読み取り専用ルートファイルシステムを使用 | ワークロードの pod spec に readOnlyRootFilesystem: true が設定されているかどうかを確認します。この設定がされていない場合、コンテナのルートファイルシステムは書き込み可能になります。これにより、悪意のあるプロセスがシステムファイルを変更するリスクが生じます。 | pod spec を変更して readOnlyRootFilesystem: true を追加します。特定のディレクトリに書き込む必要がある場合は、volumeMounts を使用します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
securityContext:
readOnlyRootFilesystem: true
特定のディレクトリ内のファイルを変更するには、volumeMounts フィールドを使用します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
securityContext:
readOnlyRootFilesystem: true
runAsNonRoot: true
volumeMounts:
- mountPath: /path/to/write
name: writeable
volumes:
- emptyDir: {}
name: writeable
|
cpuRequestsMissing | コンテナの CPU リクエストを設定 | ワークロードの Pod スペックに resources.requests.cpu が設定されているかどうかを確認します。この設定が構成されていない場合、CPU リソースが不十分なノードに Pod がスケジューリングされ、パフォーマンスが低下する可能性があります。 | Pod spec を変更して、resources.requests.cpu フィールドを追加します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
resources:
requests:
cpu: 100m
|
cpuLimitsMissing | コンテナの CPU 制限を設定 | ワークロードの Pod spec に resources.limits.cpu が設定されているかどうかを確認します。この設定がされていない場合、コンテナ内の異常なプロセスが過剰なノードリソースを消費し、ノードまたはクラスター全体の CPU リソースを枯渇させる可能性があります。 | Pod の spec を変更して、resources.limits.cpu フィールドを追加します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
resources:
requests:
cpu: 100m
limits:
cpu: 100m
|
memoryRequestsMissing | コンテナのメモリリクエストを設定 | ワークロードの Pod の spec に resources.requests.memory が設定されているかどうかをチェックします。この設定がされていない場合、Pod がメモリ不足のノードにスケジュールされ、メモリ不足 (OOM) エラーが発生する可能性があります。 | Pod の spec を変更して、resources.requests.memory フィールドを追加します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
resources:
requests:
cpu: 100m
memory: 128Mi
|
memoryLimitsMissing | コンテナのメモリ制限を設定 | ワークロードの pod spec に resources.limits.memory が設定されているかどうかを確認します。この設定がされていない場合、コンテナ内の異常なプロセスが過剰なノードリソースを消費し、ノードまたはクラスター全体のメモリを使い果たす可能性があります。 | Pod の spec を変更して、resources.limits.memory フィールドを追加します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 100m
memory: 128Mi
|
readinessProbeMissing | コンテナの readiness プローブを設定 | ワークロードの Pod spec に readinessProbe が設定されているかどうかをチェックします。readiness プローブがないと、コンテナがリクエストを処理する準備が整う前にトラフィックが送信され、アプリケーションエラーの原因となる可能性があります。 | Pod の spec を変更して、readinessProbe フィールドを追加します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 20
|
livenessProbeMissing | コンテナの liveness プローブを設定 | ワークロードの Pod の spec に livenessProbe が設定されているかチェックします。liveness プローブがない場合、応答しないコンテナは自動的に再起動されず、アプリケーションのダウンタイムにつながる可能性があります。 | Pod の spec を変更して、livenessProbe フィールドを追加します。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 20
|
tagNotSpecified | コンテナに特定のイメージタグを使用 | ワークロードの pod spec の image フィールドにイメージタグが欠落しているか、または latest タグが使用されているかどうかをチェックします。特定のイメージタグが使用されていない場合、ワークロードで予期しないバージョンのコンテナイメージが実行され、アプリケーションエラーを引き起こす可能性があります。 | Pod spec の image フィールドを、特定のイメージタグに変更してください。latest タグは使用しないでください。 例： spec:
containers:
- name: nginx
image: nginx:1.14.2
|
anonymousUserRBACBinding | 匿名ユーザーによるクラスターへのアクセスを禁止 | クラスター内のロールベースアクセス制御 (RBAC) バインディングをチェックし、匿名ユーザーにアクセスを許可する設定があるかどうかを確認します。匿名アクセスが許可されている場合、悪意のあるユーザーが機密情報を盗んだり、クラスターを攻撃したりする可能性があります。 | RBAC バインディングを修正して、匿名ユーザーがクラスターリソースにアクセスできる権限を削除します。 例： - apiGroup: rbac.authorization.k8s.io
kind: Group
name: 'foo-group'
|