見出し画像

Kubernetesの証明書CNとRBACのNameの関係 – ServiceAccountとの違いも整理！

toshi

Kubernetesの認証・認可を設定するとき、証明書のCN（Common Name）とRBACのNameの関係がちょっとややこしく感じることがありますよね。特に、ServiceAccountも「ユーザー」としてRBACで扱われるので、「結局、証明書ベースのユーザーとServiceAccountって何が違うの？」と混乱しがちです。

今回は、証明書のCNがRBACの「User名」としてどのように扱われるのか、またServiceAccountとの違いも整理してみましょう！

(1) 証明書のCN（Common Name）とは？

まず、証明書のCN（Common Name）は、簡単に言うと「この証明書の持ち主は誰か？」を示す名前です。Kubernetesでは、クライアント証明書を使ってAPIサーバーに認証すると、CNの値がそのままKubernetesの「ユーザー名」として認識されます。

例えば、クライアント証明書を使ってkubectlを実行するとき、以下のような証明書が発行されているとします。

apiVersion: v1
kind: CertificateSigningRequest
metadata:
  name: example-user-csr
spec:
  request: <Base64エンコードされたCSR>
  usages:
    - client auth

この証明書のCNが example-user だった場合、Kubernetesはそのまま**「example-userという名前のユーザー」として認識**します。

(2) CNとRBACの関係

KubernetesのRBACでは、特定の**ユーザー（証明書のCN）やグループ（証明書のO: Organization）**に対して、適切な権限を設定します。

① CNはRBACのUser名として使われる

例えば、CNをexample-userに設定した証明書を持つユーザーに権限を与えるには、以下のようにRoleBindingを設定します。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example-user-rolebinding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: example-role
subjects:
  - kind: User
    name: example-user # ← 証明書のCNと一致
    apiGroup: rbac.authorization.k8s.io

ここでname: example-userが証明書のCNの値と一致していることがポイントです。

② O（Organization）を使ってグループ管理も可能

証明書にはCNのほかにO（Organization）フィールドを設定できます。これを使うと、RBACのGroupとして認識され、組織単位で権限を管理することができます。

例えば、証明書のOをdev-teamに設定すると、その証明書を持つすべてのユーザーがdev-teamというグループに所属する形になります。

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example-group-rolebinding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: example-role
subjects:
  - kind: Group
    name: dev-team # ← 証明書のOと一致
    apiGroup: rbac.authorization.k8s.io

このようにして、個別のユーザーではなく、チーム単位でのアクセス管理も可能です。

(3) ServiceAccountとの違い – どっちも「ユーザー」だけど別モノ！

ここでややこしいのが、KubernetesにはServiceAccountという仕組みもあり、これもRBACの「ユーザー」として扱われることです。

「え、じゃあ証明書ベースのユーザーと何が違うの？」と混乱しがちですが、以下の点で明確に異なります。

① 証明書ベースのユーザー（CN）

✅ 物理的な人間（管理者や開発者）がkubectlなどを使って操作するためのアカウント
✅ 証明書（TLSクライアント証明書）を使って認証
✅ CNがそのままRBACのUser名になる

② ServiceAccount

✅ PodやアプリケーションがKubernetes APIを操作するときに使うアカウント
✅ トークン（JWTトークンなど）を使って認証
✅ 形式がsystem:serviceaccount:<namespace>:<serviceaccount名>になる

たとえば、default 名前空間にある my-app というServiceAccountは、以下のような名前で認識されます。

subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: default

Kubernetes内部では、ServiceAccountのフルネームはsystem:serviceaccount:default:my-appになります。これは、証明書ベースのCN（例: example-user）とは明らかに異なる形式です。

(4) RBACのmetadata.nameとは関係がない

もう1つ注意したいのが、RBACのmetadata.nameと証明書のCNには直接的な関係がないことです。

  • RoleやRoleBindingのmetadata.nameは、あくまでKubernetes内部のリソース識別用の名前。

  • 証明書のCNやServiceAccountの名前とは関係ない。

  • しかし、RoleBindingやClusterRoleBindingのsubjects.nameには、証明書のCNやServiceAccountの名前を指定する必要がある。

まとめ

✅ 証明書のCNはRBACのUser名として使用される
✅ 証明書のOはRBACのGroup名として使用される
✅ ServiceAccountはPodやアプリケーション用のアカウントで、CNとは別物
✅ ServiceAccountのUser名はsystem:serviceaccount:<namespace>:<name>の形式
❌ RBACのRoleやRoleBindingのmetadata.nameと証明書のCNは関係ない

つまり、証明書ベースのユーザー（CN）は「kubectlを使う人間」のためのもの、ServiceAccountは「Podやアプリが使う認証情報」と考えるとスッキリ整理できます。

証明書を使った認証やRBACの設定をするときは、**「CN＝RBACのUser名」「ServiceAccountは別枠」**というポイントを押さえておくと、迷わず設定できるはずです！

いいなと思ったら応援しよう！