はじめに：本記事について
私の所属する部署では自動車にかかわる様々な開発をしています。その中でも私のチームでは、特に コネクテッドカー（Connected Car） にかかわるバックエンド開発を担当しています。その中で私は、映像の機械学習向けの処理を効率化/分散させるためにKubernetes (K8s)ベースのアーキテクチャ検討をしています。その取り組みの一環として、Amazon Elastic Kubernetes Service（EKS）を用いた開発を経験させていただきました。この記事では、そこで得たノウハウの一部を共有いたします。
EKSの権限設定は複雑です。筆者自身も開発中に誤って過剰な権限を付与するミスを経験しました。再発防止策の一環としてここに記します。
EKSに存在する権限設定にどういったものがあり、それぞれどういった用途で用いられるかを整理します。皆様も同じ失敗をしないよう、クラスター作成前にぜひご一読いただけますと幸いです。
対象者
K8sやAmazon Web Services(AWS)についての基礎的な知識をお持ちの方を対象とします。
EKSの権限設定
EKSにおけるアクセス権限には以下の2つが存在し、それぞれ役割が異なります。
- IAMアクセスエントリ
- Pod Identity
IAMアクセスエントリはクラスター外部からのEKSクラスターへのアクセス権限を管理します。
Pod IdentityはPodからAWSリソースへのアクセス権限を管理します。
IAMアクセスエントリはK8sのRole-based access control (RBAC)に紐づいており、Pod IdentityはK8sのservice accountsに紐づいています。よって、RBACとservice accountsを説明した後に、上記2つについて説明します。
K8sの機能-Role-based access control (RBAC)
参考：https://K8s.io/docs/reference/access-authn-authz/rbac/
概要
Role-based access control (RBAC)は、K8s内のリソースに対するアクセス権を管理する機能です。Subjects(service accounts、users、groups)に対してK8s内リソースへの操作を許可します。
Subjectsについて
Subjectsには以下3種類があります。
service accounts
K8sクラスター内のリソース（Podなど）が用いるアカウントです
users
システムを操作する利用者が用いるアカウントです
groups
service accountsやusersが属するグループです
RBACの仕組み
Subjectsに対して、role(K8s内のリソースに対して何の操作を許可するかを定義したもの)を紐づけることによって、そのSubjectが操作権限を持つという仕組みです。
例えば、開発者グループに属するアカウントにPodを作成する権限を付与したい場合は、開発者のgroupsに対してPod作成の権限をもつroleを紐づけます。
EKSの機能-IAMアクセスエントリ
参考：https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html
概要
クラスター外部からのEKSクラスターへの操作を「どのIAMエンティティ」に対して許可するかを設定するものです。IAMアクセスエントリによって許可されていない場合は一切クラスターを操作できません。
クラスター作成時に使用していたIAMエンティティに関しては自動でIAMアクセスエントリが作成されます。
IAMアクセスエントリの仕組み
IAMエンティティが具体的にクラスターに対してどのような操作が可能なのかは、前述したK8sのRole-based access control (RBAC)を用いて設定します。
とはいえ、IAMアクセスエントリにおいては利用者がRBACを意識することは少なく、IAMアクセスエントリの設定画面にて以下記載のポリシーを選択すれば、EKS側が自動でRBACの設定をしてくれます。
参考：https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html
EKSの機能-Pod Identity
参考：https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html
概要
EC2に対してIAMロールを付与するのと同様に、Podに対してIAMロールを付与することでAWSのリソースに対する権限を付与できる機能です。
Pod Identityの仕組み
Podに対して権限を付与すると説明しましたが、正確にはPodが使用するservice accountsに対して権限を付与します。service accountsに対して、IAMロールによってAWS内のリソースに対する権限を与えることとなります。
おわりに
EKSは、K8sの権限管理方式とAWSの権限管理方式が連携しているため、AWSのマネージドサービスの中では権限管理が複雑な部類になるかと思います。
筆者は、IAMアクセスエントリとPod Identityの違いが分からず苦労しました。
本記事がクラスター構築時の権限設定の一助となれば幸いです。
我々のチームでは自動車を軸に、R&Dから商用開発まで幅広に開発をしています。
** 興味がある方は **
** 自チームの取り組み紹介 **
** 過去の記事 **
** 本件に関するお問い合わせ先 **
株式会社NTTデータ
システムインテグレーション事業本部
ビジネスエンジニアリングサービス事業部
自動車開発統括部
E-mail：connected-car-cloud@hml.nttdata.co.jp
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。