認可モードが AlwaysAllow に設定されている

AlwaysAllow の代わりに、各コンポーネントに適した認可ポリシーを使用してください。

説明

AlwaysAllow は、認証を通過したリクエストの操作権限を制限しません。認証と認可は別の処理であり、認証済みユーザーや許可された匿名リクエストに対しても、必要な権限の境界が失われる可能性があります。kube-apiserver と kubelet の認可設定をそれぞれ確認してください。

想定される影響

  • 不要なリソースの参照・変更やノード操作を許可する可能性があります。
  • 侵害されたアカウントやワークロードが制御プレーンやノードの権限を悪用すると、他のワークロードにも影響するおそれがあります。

対処方法

  • kube-apiserver では必要なロールとバインディングを準備し、AlwaysAllow を RBAC など権限を検査する構成に変更してください。
  • kubelet では、API サーバーに認可を委任する Webhook と必要な接続・権限を設定してください。kubelet に RBAC モードを直接指定しないでください。
  • 起動引数と設定ファイルを合わせて確認し、必要なリクエストが成功して権限のないリクエストが拒否されることをテストしてください。

例

過去の Kubernetes 1.6 API サーバーの起動引数を比較する抜粋です。サポートされるバージョンへ移行し、残りの制御プレーン設定は別途用意してください。両方の例で匿名認証を無効にしており、変更後には適切な RBAC ロールとバインディングが必要です。

変更前

yaml
apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
    - name: command-demo-container
      image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
      command: ["kube-apiserver"]
      args:
        ["--anonymous-auth=false", "--authorization-mode=AlwaysAllow"]
  restartPolicy: OnFailure

認証済みリクエストを AlwaysAllow で認可し、操作ごとの権限を制限しません。

変更後

yaml
apiVersion: v1
kind: Pod
metadata:
  name: command-demo
  labels:
    purpose: demonstrate-command
spec:
  containers:
    - name: command-demo-container
      image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
      command: ["kube-apiserver"]
      args:
        ["--anonymous-auth=false", "--authorization-mode=RBAC"]
  restartPolicy: OnFailure

RBAC ポリシーに基づいて認可します。管理者とシステムコンポーネントに必要な権限を先に準備してください。

参考資料