Simple minds think alike

より多くの可能性を

kubernetesの認証と認可、サービスアカウントとユーザーアカウントの概念

Kubernetesのドキュメントを読んで、認証と認可、サービスアカウントとユーザーアカウントの概念をまとめてみました。

kubernetes.io

認証と認可

  • 認証(Authentication)とは
    • Kubernetes API内のリソースにアクセスできるかチェックする仕組みです。
    • 認証に失敗するとアクセスできません。
  • 認可(Authorization)とは
    • Kubernetesクラスタ内のどのリソースにアクセスできるかをチェックする仕組みです。
    • 認可されるリソースのみアクセスできます。

Kubernetesでは、クラスタ内部のリソースにアクセスするためにKubenetes APIを介してアクセスするのですが、その認証ができなければ内部リソースを操作することができません。

認証の対象(サービスアカウントとユーザーアカウント)

Kubernetes APIに認証されるアカウントは

  • Kubernetes内部で管理するサービスアカウント
    • CoreDNSのような内部プロセス
  • Kubernetes外部で管理するユーザーアカウント

の2種類があります。

  • サービスアカウントは
    • ネームスペースに1対1に紐付けてKubernetes内のServiceAccountというリソースで管理されます。
    • ネームスペース内に一意の名前のサービスアカウントであればよく、他のネームスペースで同じ名前のサービスアカウントが存在しても、まったく関係がありません。
  • 逆に、ユーザーアカウントは
    • ネームスペース等のKubernatesのリソースに紐付けずに、Kubernetes外部で管理されます。
    • なので、Kubernetes内で管理するためのリソースもありませんし、kubectl get users や useraccountsのようなコマンドはありませんし、
    • クラスタ全体で一意の名前である必要があります。

認証方式

サポートされている認証方式は色々ありますが、AWSユーザーはまずは下の2つだけ覚えておけば、ほとんどのユースケースで対応できそうです。

  • Service Account Tokens (自動的に有効になる)
  • Webhook Token Authentication

認証するアカウントは、ユーザーアカウントとサービスアカウント(後述)の2つがあります。

Service Account Tokens

Service Account Tokensは、サービスアカウントを認証する方式で、自動的に有効になります。

以下のようなコマンドを実行して

$ kubectl create serviceaccount jenkins

サービスアカウントを作ると31ada4fd-adec-460c-809a-9e56ceb75269のようなトークンが発行され、Secretというリソースに保存されます。

作ったサービスアカウントでKubernetes APIにアクセスする際にはHTTPリクエストヘッダに

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

のように指定してアクセスし、APIがどのサービスアカウントか識別します。

Webhook Token Authentication

Amazon EKSがIAMロールを認証する際に使っている方式(主にユーザーアカウントを認証する方式)なのですが、以下の図がわかりやすいと思います。

(Weibel, 2019)

このIAMのケースでは、Kubernetes APIにアクセスするとaws-iam-authenticator serverに認証を委譲し、IAM identityトークンがKubernatesユーザーに変換され、Webhookに返すという方式で使っているようです。

認証方式の有効化

実運用の際にはサービスアカウントとユーザーアカウントの両方を使うことになるので、

  • サービスアカウント
    • Service Account Tokens を有効する
  • ユーザーアカウント
    • Webhook Token Authentication を有効にする

のように複数の認証方式を有効にします。

認証の順番

複数の認証方式が有効の場合、以下のように

認証方式を順番に試していき、認証が通った時点で、Kubenetes APIに認証情報を返します。(短絡評価)

また、認証方式の順番は保証されません。