Kubernetesのドキュメントを読んで、認証と認可、サービスアカウントとユーザーアカウントの概念をまとめてみました。
認証と認可
- 認証(Authentication)とは
- Kubernetes API内のリソースにアクセスできるかチェックする仕組みです。
- 認証に失敗するとアクセスできません。
- 認可(Authorization)とは
- Kubernetesクラスタ内のどのリソースにアクセスできるかをチェックする仕組みです。
- 認可されるリソースのみアクセスできます。
Kubernetesでは、クラスタ内部のリソースにアクセスするためにKubenetes APIを介してアクセスするのですが、その認証ができなければ内部リソースを操作することができません。
認証の対象(サービスアカウントとユーザーアカウント)
Kubernetes APIに認証されるアカウントは
- Kubernetes内部で管理するサービスアカウント
- CoreDNSのような内部プロセス
- Kubernetes外部で管理するユーザーアカウント
- 開発者等。アカウントはAWS IAM、Active Directory、LDAPなど外部でアカウント管理
の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に認証情報を返します。(短絡評価)
また、認証方式の順番は保証されません。