OpenShiftでSCCやroleの追加設定をしたら確認しようという話

背景

• あるソフトウェアをOpenShiftクラスターで稼働させる際に、以下のようなコマンドでService AccountへのSCCの追加を行なった。しかし設定後の確認方法を理解していなかったため、設定ミスがあったことに気づかなかった。その結果、他のpodを起動するユーザーまで変わってしまい、podが起動できなかったり、うまく動作しない問題が発生した・・・。

  oc adm policy add-scc-to-user <scc_name> -z <serviceaccount_name>
  

• 同様に、ユーザーへのロールの設定を行った際にも確認方法がよく分からなかった。

• そもそもSCCやロールについて十分理解して設定すべきだが、最低限設定した内容が想定通りになっているかを確認する必要があると痛感した。ただ、意外とSCCやロールの確認方法が分かりづらかったので手順を残しておく。

• 本記事はOpenShift Container Platform 4.7を前提としています。

参考にさせていただいた情報

• OpenShift 4.7マニュアル - SCC (Security Context Constraints) の管理
• 【OpenShift】oc adm policy add-scc-to-userでの変更とClusterRoleBindingの関係
• OpenShift 4.7マニュアル - RBAC の使用によるパーミッションの定義および適用
• Security Context Constrains(SCC)の適用プロセス on OpenShift

SCCやRoleの設定について理解したこと

• oc adm policy add-scc-to-userコマンドや oc policy add-role-to-userコマンドでユーザーへSCCやRoleの追加を行なった場合、RoleBindingやClustomerRoleBindingというRoleとユーザーとの結び付けを行うリソースが作成される。（参考情報）
• CustomerRoleBindingとRoleBindingの違いは、CustomerRoleBindingはクラスター全体の権限設定を行うのに対し、RoleBindingはネームスペース内の権限設定を行う点にある。(参考情報)

学んだこと（教訓)

• oc adm policy add-scc-to-userコマンドや oc policy add-role-to-userコマンドなどでSCCやRoleの追加を行なったら、その設定が想定通りにRoleBindingやClustomerRoleBindingに反映されているか（設定ミスがないか）確認が必要だということ。

SCCやロールの追加と確認方法

パターン1. oc adm policy add-scc-to-userコマンドでService AccountへのSCC追加を行なう場合

• 設定コマンド

oc adm policy add-scc-to-user <scc_name> -z <serviceaccount_name>

• 確認コマンド

oc describe clusterrolebinding system:openshift:scc:<scc_name>

または

oc get clusterrolebinding system:openshift:scc:<scc_name> -o wide

実際に実行した例は以下のとおり。

• 設定コマンド例

oc adm policy add-scc-to-user anyuid -z gitlab-runner-sa

• このコマンドは、「現在のプロジェクトのService Account gitlab-runner-saにSCC anyuid を追加する」という意味。
• -zオプションについてはOpenShiftバージョン3.9のマニュアルに記載がある。

重要
上記の -z フラグについては、誤字を防ぎ、アクセスが指定されたサービスアカウントのみに付与されるため、その使用をを強く推奨します。プロジェクトにいない場合は、-n オプションを使用して、それが適用されるプロジェクトの namespace を指定します。

• 確認コマンドと出力の例
  • Role:以下にSCCの情報が、Subjects:以下に設定対象のService Account情報が表示される。
  • 以下の場合、namespace gitlab-system のService Accout gitlab-runner-saにSCC anyuidが設定されていることがわかる。
  • うまく設定されていない場合は、このclusterrolebindingのSublects:が正しくなかったり、clusterrolebinding自体が存在しなかったりする。

$ oc describe clusterrolebinding system:openshift:scc:anyuid
Name:         system:openshift:scc:anyuid
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  system:openshift:scc:anyuid
Subjects:
  Kind            Name              Namespace
  ----            ----              ---------
  ServiceAccount  gitlab-runner-sa  gitlab-system

または

oc get clusterrolebinding system:openshift:scc:anyuid -o wide
NAME                          ROLE                                      AGE    USERS   GROUPS   SERVICEACCOUNTS
system:openshift:scc:anyuid   ClusterRole/system:openshift:scc:anyuid   105d                    gitlab-system/gitlab-runner-sa

• このコマンドの場合は、表示がシンプルだがROLEとSERVICEACCOUNTSの内容を確認すればよい。

パターン2. oc policy add-role-to-userコマンドで特定のプロジェクトでService Accountへのロールの追加を行なう場合

• 設定コマンド

oc policy add-role-to-user <role_name> "system:serviceaccount:<namespace_name>:<serviceaccount_name>" --namespace=<namespace_name>

• 確認コマンド

oc describe rolebinding <role_name> -n <namespace_name>

または

oc get rolebinding <role_name> -n <namespace_name> -o wide

実際に実行した例は以下のとおり。

• 設定コマンド例

oc policy add-role-to-user system:image-puller "system:serviceaccount:sample-stg:default" --namespace=sample-dev

• このコマンドは、「sample-devプロジェクトにて、sample-stgプロジェクトのService Account defaultにロール system:image-puller を追加する」という意味。

• 確認コマンドと出力の例

  • Role:以下にロールの情報が、Subjects:以下に設定対象のService Account情報が表示される。
  • 以下の場合、namespacesample-stgのService Accout defaultにClusterRole system:image-pullerが設定されていることがわかる。
  • うまく設定されていない場合は、このrolebindingのSublects:が正しくなかったり、rolebinding自体が存在しなかったりする。

$ oc describe rolebinding system:image-puller -n sample-dev
Name:         system:image-puller
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  system:image-puller
Subjects:
  Kind            Name     Namespace
  ----            ----     ---------
  ServiceAccount  default  sample-stg

または

$ oc get rolebinding system:image-puller -o wide -n sample-dev
NAME                  ROLE                              AGE   USERS   GROUPS   SERVICEACCOUNTS
system:image-puller   ClusterRole/system:image-puller   14h                    sample-stg/default

• このコマンドの場合は、表示がシンプルだがROLEとSERVICEACCOUNTSの内容を確認すればよい。

おまけ. oc adm policyコマンドとoc policyコマンドの違いは？

• 上記の内容ではoc adm policyコマンドとoc policyコマンドを例に説明をしたが、そもそも両者がどう違うのかよくわからなかった。
• CLIリファレンスを調べたところ、oc policyコマンドは「上級開発者のCLIコマンド」に分類されており、oc adm policyコマンドは「OpenShift CLI 管理者コマンド」に分類されていることがわかった。
• それぞれの説明は以下のとおり。　　
  • oc adm policyコマンド　「クラスター上のロールおよびポリシーを管理します。」
  • oc policyコマンド　「認可ポリシーを管理します。」
    • 例: edit ロールの現在のプロジェクトの user1 への追加
• つまり両者の違いは以下のように理解した。
  • oc adm policyコマンドは管理者向けでクラスター全体のロールやポリシーを管理する。
  • oc policyコマンドは開発者向けでネームスペース内のロールやポリシーを管理する。