Oracle Cloud Native Environmentでのロールベースのアクセス制御の使用

イントロダクション

Kubernetesクラスタへのデプロイメントの数が増えるにつれて、管理のサポートが必要になる場合があります。Kubernetes APIには、ユーザーを追加し、クラスタに対する権限を定義する機能があります。

ユーザーが認証されると、Kubernetesは、ユーザーが実行する権限があるアクションを確認します。ロールベースのアクセス制御(RBAC)は、Kubernetesでネイティブにサポートされ、Oracle Cloud Native Environment (Oracle CNE)でデフォルトで有効になっています。これを、一般的に使用されるアクセス制御方法の1つにします。RBACでは、クラスタ・リソースへのユーザーのアクセスを制限するルールを適用することで、Kubernetes環境にデプロイされたリソースへのアクセスを管理できます。これらのルールは、ロールを使用してネームスペースを制限するか、ClusterRoleを使用してクラスタ全体で制限できます。

Kubernetesのロールベース・アクセス制御(RBAC)の主要なコンポーネントについて理解しておくと役に立ちます。これらのコンポーネントは次のとおりです。

Kubernetesクラスタへのアクセスを管理するもう1つの方法は、属性ベースのアクセス制御(ABAC)です。これにより、RBACと比較してポリシーをより詳細にチューニングできます。ただし、このチュートリアルは対象外です。

このチュートリアルでは、RBACを使用してKubernetesクラスタへのアクセスを管理するための基本を説明し、簡単なユースケースを示します。

Oracle Cloud Native Environment 2の詳細は、現在のリリース・ドキュメント・サイトを参照してください。

目的

このチュートリアルでは、次のことを学習します。

前提条件

Oracle Cloud Native Environmentの構成

ノート:独自のテナンシで実行している場合は、演習環境をデプロイする前に、linux-virt-labs GitHubプロジェクトREADME.mdを読み、前提条件を完了してください。

  1. Lunaデスクトップでターミナルを開きます。

  2. linux-virt-labs GitHubプロジェクトをクローニングします。

    git clone https://github.com/oracle-devrel/linux-virt-labs.git

  3. 作業ディレクトリへ移動します。

    cd linux-virt-labs/ocne2

  4. 必要なコレクションをインストールします。

    ansible-galaxy collection install -r requirements.yml

  5. 演習環境をデプロイします。

    ansible-playbook create_instance.yml -e localhost_python_interpreter="/usr/bin/python3.6" -e install_ocne_rpm=true -e create_ocne_cluster=true -e "ocne_cluster_node_options='-n 1 -w 1'"

    無料の演習環境には、ローカル・ホストで実行される再生のansible_python_interpreterを設定する追加の変数local_python_interpreterが必要です。この変数は、python3.6モジュールの下にあるOracle Cloud Infrastructure SDK for PythonのRPMパッケージが環境によってインストールされるため必要です。

    デフォルトのデプロイメント・シェイプでは、AMD CPUおよびOracle Linux 8が使用されます。Intel CPUまたはOracle Linux 9を使用するには、デプロイメント・コマンドに-e instance_shape="VM.Standard3.Flex"または-e os_version="9"を追加します。

    重要:プレイブックが正常に実行されるまで待機し、一時停止タスクに到達します。プレイブックのこの段階では、Oracle CNEのインストールが完了し、インスタンスの準備ができました。前回の再生をノートにとります。この再生では、デプロイするノードのパブリックIPアドレスとプライベートIPアドレス、および演習の実行中に必要なその他のデプロイメント情報が出力されます。

Kubernetesクラスタへのアクセス

  1. 端末を開き、SSH経由でocneインスタンスに接続します。

    ssh oracle@<ip_address_of_instance>

  2. クラスタが安定し、すべてのポッドが実行中の状態でレポートされるまで待機します。

    watch kubectl get pods -A

    すべてのポッドに「実行中」のSTATUSが表示されたら、Ctrl-Cと入力してwatchコマンドを終了します。

  3. ノードの数を確認します。

    kubectl get nodes

現在のRBAC構成の確認

RBACは、Kubernetesクラスタにデプロイされたリソースに対して実行するアクションの権限を管理します。RBACが有効になっていることを確認し、クラスタ内のデフォルトのロールを確認します。

  1. RBACが有効になっていることを確認します。

    rbac.authorization.k8s.io APIが表示されている場合は、RBACが構成され、ユーザーまたはサービス・アカウントがクラスタ・リソースに対して実行できるアクションを制御するために使用されます。

    kubectl api-versions | grep rbac

    出力例:

    [oracle@ocne ~]$ kubectl api-versions | grep rbac
rbac.authorization.k8s.io/v1

  2. 組込みクラスタ・ロールを表示します。

    kubectl get clusterroles | grep admin

    出力例:

    [oracle@ocne ~]$ kubectl get clusterroles | grep admin
admin                                                                  2025-07-23T10:21:55Z
cluster-admin                                                          2025-07-23T10:21:55Z
system:aggregate-to-admin                                              2025-07-23T10:21:55Z
system:kubelet-api-admin                                               2025-07-23T10:21:55Z

    通常のユーザーはadminおよびcluster-adminロールを使用しますが、RBAC APIは内部コンポーネントのsystem:ロールを予約します。

  3. cluster-adminの権限をリストします。

    kubectl describe clusterrole cluster-admin

    出力例:

    [oracle@ocne ~]$ kubectl describe clusterrole cluster-admin
Name:         cluster-admin
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  *.*        []                 []              [*]
             [*]                []              [*]

    動詞列およびリソース列のアスタリスクは、cluster-adminロールが任意のアクションを実行できることを意味します。各Kubernetesリリースで使用可能な操作(動詞)の高レベル・リストは、そのリリースのAPI概要で使用できます。たとえば、Kubernetes v1.33.0です。各リソース・タイプで使用可能な有効な操作(動詞)の詳細なリストは、コマンドラインからkubectl api-resources -o wideを実行することで入手できます。

    ただし、kubectlにログインしていないため、Kubernetesはコマンドを実行しているユーザーが誰であるかをどのように認識しますか。本番システムでは通常、認証にLDAPサーバーを使用します。外部認証システムを使用できない場合は、ServiceAccountを使用できます。

    ノート: ServiceAccountsは、CI/CDパイプラインなどの自動ワークロードで使用されます。ただし、テストにも使用できます。

ロールの作成

ロールは、単一のネームスペース内のKubernetesリソースにアクセスする権限を定義するネームスペース制限されたリソースです。

ネームスペースおよびロールの作成

  1. ネームスペースを作成します。

    この例の新しいネームスペースを作成します。

    kubectl create namespace rbac-example

  2. ロールを作成します。

    rbac-exampleネームスペース内のポッドおよびデプロイメントに読取り専用アクセス権('get'および'list'権限)を付与するロールを作成します。

    cat << EOF | tee pod-reader-role.yaml > /dev/null
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: rbac-example
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list"]
EOF

    説明:

    • rules: - ロールに付与される権限を定義します。この例では、2つのルールを定義します(次を参照)。
    • apiGroups: [""] - このルールにバインドされたユーザーまたはサービス・アカウントが、rbac-exampleネームスペース内のポッドを取得およびリストすることを許可します。
    • apiGroups: ["apps"] - このルールにバインドされたユーザーまたはサービス・アカウントが、rbac-exampleネームスペース内のデプロイメントを取得およびリストすることを許可します。

  3. ファイルを適用します。

    kubectl apply -f pod-reader-role.yaml

  4. 新しく作成したpod-readerロールの権限を確認します。

    kubectl describe role/pod-reader -n rbac-example

    出力例:

    [oracle@ocne ~]$ kubectl describe role/pod-reader -n rbac-example
Name:         pod-reader
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources         Non-Resource URLs  Resource Names  Verbs
  ---------         -----------------  --------------  -----
 pods              []                 []              [get list]
 deployments.apps  []                 []              [get list]

ユーザーの作成およびロールへのバインド

  1. pod-reader-userという新しいServiceAccountユーザーを作成し、pod-readerロールにバインドします。

    cat << EOF | tee pod-reader-user.yaml > /dev/null
apiVersion: v1
kind: ServiceAccount
metadata:
  name: pod-reader-user
  namespace: rbac-example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: rbac-example
roleRef:
  name: pod-reader
  kind: Role
subjects:
- kind: ServiceAccount
  name: pod-reader-user
  namespace: rbac-example
EOF

    説明:

    • ServiceAccountはサービス・アカウントを作成します。
      • name: - サービス・アカウント・ユーザーの名前(pod-reader-user)。
      • namespace - 作成されるネームスペース(rbac-example)。
    • RoleBindingは、ネームスペース関連の権限をサービス・アカウントに付与します。
      • roleRef: - バインディング・ロールを指定します。この例では、pod-readerというロールを参照します。
      • subjects: - 権限を付与するエンティティを指定します。この例では、pod-reader-userというサービス・アカウントです。

  2. ファイルを適用します。

    kubectl apply -f pod-reader-user.yaml

RoleBindingをテストします。

次に、新しいポッドを作成し、新しく作成したpod-reader-userサービス・アカウントを使用してそれにアクセスして、RoleBindingをテストします。

  1. 新しいテスト・デプロイメントを作成します。

    cat << EOF | tee testpod.yaml > /dev/null
apiVersion: v1
kind: Pod
metadata:
  name: test-pod
  namespace: rbac-example
spec:
  containers:
  - name: test-container
    image: ghcr.io/oracle/oraclelinux9-nginx:1.20
    ports:
    - containerPort: 80
  serviceAccountName: pod-reader-user
EOF

    説明:

    • spec:は、ポッドの目的の状態を定義します。
      • containers: - ポッドで実行するコンテナのリストを指定します。この例では、コンテナは1つのみです。
        • name: - コンテナの名前(test-container)。
        • image: - 使用するイメージ(ghcr.io/oracle/oraclelinux9-nginx:1.20)。
        • ports: - コンテナによって公開されるポートを指定します。この例では、ポート80 (containerPort: 80)です。
      • serviceAccountName: - ポッドに使用するサービス・アカウントを指定します。この構成では、ポッドはpod-reader-userサービス・アカウントに割り当てられた権限および資格証明を使用します。

  2. ファイルを適用します。

    kubectl apply -f testpod.yaml

  3. ここで、pod-reader-user ServiceAccountを使用してポッドにアクセスしてみてください。

    kubectl auth can-i get pod/test-pod --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example

    pod-reader-userにポッドにアクセスする権限があることを示すyesが出力として表示されます。

    ノート: kubectl auth can-i機能を使用して、新しく作成されたServiceAccountユーザー・アカウントとしてコマンドを実行し、アクションが許可されていることを確認します。

  4. ServiceAccountが期待どおりに機能することを確認します。

    kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example

    出力例:

    [oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user get pods -n rbac-example
NAME       READY   STATUS    RESTARTS   AGE
test-pod   1/1     Running   0          109s

  5. pod-reader-userロールを使用してポッドの削除を試行します。

    kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example

    出力例:

    [oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:pod-reader-user delete pod test-pod -n rbac-example
Error from server (Forbidden): pods "test-pod" is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot delete resource "pods" in API group "" in the namespace "rbac-example"

    pod-reader-userロールは、rbac-exampleのポッドを削除できません。新たなポットが出来るのでしょうか。

  6. pod-reader-roleロールを使用してポッドの実行を試みます。

    kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:default:my-serviceaccount -n rbac-example

    出力例:

    [oracle@ocne ~]$ kubectl run nginx1 --image=ghcr.io/oracle/oraclelinux9-nginx:1.20 --as=system:serviceaccount:rbac-example:pod-reader-user -n rbac-example
Error from server (Forbidden): pods is forbidden: User "system:serviceaccount:rbac-example:pod-reader-user" cannot create resource "pods" in API group "" in the namespace "rbac-example"

    pod-reader-userロールは、クラスタのrbac-exampleネームスペース内のポッド・リソースに対してgetおよびlistアクションのみを実行できるため、このエラーは正しいです。その他のアクション(deleteまたは create)は許可されません。

ClusterRoleの作成

ClusterRolesはロールに似ていますが、クラスタ全体のリソースに対して許可される権限を定義します。

ノート:広すぎる権限を付与する場合は注意してください。かわりに、最小の「最小権限の原則」を使用して、割り当てられたタスクを完了するために必要な権限のみをユーザーおよびサービス・アカウントに付与します。

ClusterRoleおよびClusterRoleBindingの作成

前の例では、ネームスペース固有のユーザーおよびロールを作成する方法を示します。次のステップでは、ClusterRoleを作成してユーザーにバインドし、クラスタ全体の管理アクセス権を付与する方法を示します。

  1. 新しいClusterRoleを作成します。

    このClusterRoleを使用すると、ユーザーはこれに追加して、クラスタ全体のすべてのリソースに対して任意のアクションを実行できます。

    cat << EOF | tee cluster-admin-clusterrole.yaml > /dev/null
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin-cr
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
EOF

    説明:

    • rules: - ClusterRoleに付与される権限を定義します。この例では、ルールが1つのみです。
      • apiGroups: ["*"] - ルールがすべてのAPIグループに適用されるように指定します。
      • resources: ["*"] - ルールがAPIグループのすべてのリソースに適用されることを指定します。
      • verbs: ["*"] - ルールが、get、list、create、deleteなど、リソースに対して可能なすべての動詞を付与することを指定します。

  2. ファイルを適用します。

    kubectl apply -f cluster-admin-clusterrole.yaml

  3. ClusterRoleBindingを作成して、ClusterRoleを新しいユーザーにバインドします。

    ClusterRoleBindingは、以前に作成したRoleBindingと似ていますが、クラスタ・スコープです。

    cat << EOF | tee cluster-admin-user.yaml > /dev/null
apiVersion: v1
kind: ServiceAccount
metadata:
  name: cluster-admin-user
  namespace: rbac-example
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-crb
roleRef:
  name: cluster-admin-cr
  kind: ClusterRole
subjects:
- kind: ServiceAccount
  name: cluster-admin-user
  namespace: rbac-example
EOF

    説明:

    • subjects: - ClusterRoleで権限を付与するエンティティを定義します。この例では、cluster-admin-userサービス・アカウントです。

  4. ファイルを適用します。

    kubectl apply -f cluster-admin-user.yaml

ClusterRoleBindingをテストします。

  1. 別のネームスペースのリソースにアクセスしようとして、クラスタ・ロールをテストします。たとえば、default名前空間です。

    kubectl auth can-i list pods --as=system:serviceaccount:rbac-example:cluster-admin-user -n default

    cluster-admin-userにcluster-adminアクセス権があることを示すyesが出力として表示されます。

  2. 新しく作成されたClusterRoleが期待どおりに動作することを確認します。

    kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A

    出力例:

    [oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
kube-flannel   kube-flannel-ds-ptwkz                          1/1     Running   0          6h58m
kube-flannel   kube-flannel-ds-wn2g6                          1/1     Running   0          6h58m
kube-system    coredns-7cbdbfd99c-7xqkl                       1/1     Running   0          6h59m
kube-system    coredns-7cbdbfd99c-k2ssb                       1/1     Running   0          6h59m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          6h59m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          6h59m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          6h59m
kube-system    kube-proxy-48rm5                               1/1     Running   0          6h59m
kube-system    kube-proxy-h4kd2                               1/1     Running   0          6h58m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          6h59m
ocne-system    ocne-catalog-577b7cd5f9-bnvtm                  1/1     Running   0          6h58m
ocne-system    ui-846bddd4b-lnrwm                             1/1     Running   0          6h58m
rbac-example   test-pod                                       1/1     Running   0          6h34m

    この出力は、新しく作成されたClusterRoleが、クラスタに定義されているすべてのネームスペースにアクセスできることを確認します。

ClusterRoleユーザーが新しいデプロイメントを作成できることを確認します

ClusterRoleをテストして、割り当てられたユーザーが新しいデプロイメントを作成できるかどうかを確認します。次に、新しく作成したClusterRoleを使用してアクセスを試みます。

  1. 新しいテスト・デプロイメントを作成します。

    cat << EOF | tee testpod2.yaml > /dev/null
apiVersion: v1
kind: Pod
metadata:
  name: test-pod2
  namespace: default
spec:
  containers:
  - name: test-container
    image: ghcr.io/oracle/oraclelinux9-nginx:1.20
    ports:
    - containerPort: 8080
EOF

    この配備は、以前に使用した rbac-example名前空間ではなく、'default'名前空間に配備されることに注意してください。

  2. ファイルを適用します。

    kubectl apply -f testpod2.yaml

  3. デプロイメントが正常に完了したことを確認します。

    kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A

    出力例:

    [oracle@ocne ~]$ kubectl --as=system:serviceaccount:rbac-example:cluster-admin-user get pods -A
NAMESPACE      NAME                                           READY   STATUS    RESTARTS   AGE
default        test-pod2                                      1/1     Running   0          28s
kube-flannel   kube-flannel-ds-shgh7                          1/1     Running   0          38m
kube-flannel   kube-flannel-ds-zzrgh                          1/1     Running   0          38m
kube-system    coredns-7cbdbfd99c-jg6lz                       1/1     Running   0          38m
kube-system    coredns-7cbdbfd99c-wh5g4                       1/1     Running   0          38m
kube-system    etcd-ocne-control-plane-1                      1/1     Running   0          38m
kube-system    kube-apiserver-ocne-control-plane-1            1/1     Running   0          38m
kube-system    kube-controller-manager-ocne-control-plane-1   1/1     Running   0          38m
kube-system    kube-proxy-5qngx                               1/1     Running   0          38m
kube-system    kube-proxy-6fz2q                               1/1     Running   0          38m
kube-system    kube-scheduler-ocne-control-plane-1            1/1     Running   0          38m
ocne-system    ocne-catalog-577b7cd5f9-vz782                  1/1     Running   0          38m
ocne-system    ui-846bddd4b-bbhtj                             1/1     Running   0          38m
rbac-example   test-pod                                       1/1     Running   0          21m

    新しいClusterRoleで別のネームスペースへの新しいデプロイメントが許可されていることを確認します。

次のステップ

このチュートリアルでは、Kubernetesリソースへのアクセスを管理するロールを作成して、Kubernetesでロールベースのアクセス制御(RBAC)を設定および使用する方法を示します。これを実現するには、ロールおよびバインディングを定義して、ネームスペース内のリソースまたはクラスタ全体のリソースで許可されるアクションを制御します。このように、RBACが提供するきめ細かい制御は、特に大規模なデプロイメントにおいて、Kubernetes環境を保護するために不可欠です。追加のチュートリアルおよびコンテンツについては、Oracle Linuxトレーニング・ステーションを参照してください。

その他の学習リソース

docs.oracle.com/learnで他のラボを確認するか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスして、Oracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。