認証と認可
**認証**タブをクリックしてServiceAccountsセクションに移動すると、名前空間ごとにKubernetesのサービスアカウントリソースを表示できます。
追加の例についてはセキュリティモジュールをご確認ください。
ServiceAccountはPod内で実行されるプロセスにIDを提供します。Podを作成する際、サービスアカウントを指定しない場合、同じ名前空間内のデフォルトのサービスアカウントが自動的に割り当てられます。
特定のサービスアカウントの詳細を表示するには、名前空間まで移動し、表示したいサービスアカウントをクリックすると、ラベル、アノテーション、イベントなどの追加情報が表示されます。以下はcatalogサービスアカウントの詳細ビューです。
EKSでは、リクエストが認可（アクセス許可の付与）される前に、認証（ログイン）する必要があります。KubernetesはREST APIリクエストに共通する属性を期待します。つまり、EKSの認可はアクセス制御にAWS Identity and Access Managementと連携します。
このラボでは、Kubernetesの**ロールベースアクセス制御（RBAC）**リソース：ClusterRoles、Roles、ClusterRoleBindings、RoleBindingsを表示します。RBACは、EKSクラスターにマッピングされたIAMロールに従って、EKSクラスターとそのオブジェクトへの制限された最小特権アクセスを提供するプロセスです。以下の図は、ユーザーまたはサービスアカウントがKubernetesクライアントとAPIを介してEKSクラスター内のオブジェクトにアクセスしようとしたときに、アクセス制御がどのように流れるかを示しています。
追加の例についてはセキュリティモジュールをご確認ください。
**Role**はユーザーに適用される一連のアクセス許可を定義します。ロールベースアクセス制御（RBAC）は、組織内の個々のユーザーの役割に基づいてコンピュータやネットワークリソースへのアクセスを規制する方法です。Roleは常に特定の名前空間内でアクセス許可を設定し、Roleを作成する際には、それが属する名前空間を指定する必要があります。
リソースタイプ - 認可セクションでは、クラスターのClusterRolesとRolesリソースを名前空間ごとに表示できます。
cluster-autoscaler-aws-cluster-autoscalerロールをクリックすると、そのロールの詳細が表示されます。以下のスクリーンショットは、名前空間kube-systemに作成されたcluster-autoscaler-aws-cluster-autoscalerロールを示しており、configmapsリソースに対する削除、取得、更新の権限を持っています。
ClusterRolesはクラスター全体にスコープされたルールのセットであり、名前空間ではないため、Roleとは異なります。ClusterRolesは付加的であり、「拒否」ルールを設定することはできません。通常、クラスター全体の権限を定義するためにClusterRolesを使用します。
Role bindingはロールの権限をユーザーまたはユーザーのセットに付与します。Rolebindingsは作成時に特定の名前空間に割り当てられます。Rolebindingリソースは、サブジェクト（ユーザー、グループ、またはサービスアカウント）のリストと、付与されるロールへの参照を保持しています。RoleBindingはpods、replicasets、jobs、deploymentsなど、特定の名前空間内の権限を付与します。一方、ClusterRoleBindingはノードなどのクラスタースコープのリソースを付与します。
ClusterRoleBindingはClusterRolesをユーザーのセットに接続します。これらはクラスターにスコープされ、RolesやRoleBindingsのように名前空間にバインドされません。
