EKSクラスタを操作できるユーザーを追加した時の疑問
チームでEKSのクラスタを管理する場合、クラスタを作成したユーザー以外に、別途ユーザーを追加する必要が生じます。
その場合、
AWSのドキュメント「クラスターのユーザーまたは IAM ロールの管理」
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/add-user-role.html
では、
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapUsers: |
- userarn: arn:aws:iam::555555555555:user/admin
username: admin
groups:
- system:masters
みたいな感じで、ConfigMapにmapUsersセクションを追加し、userarnでIAMユーザーのリソース名を指定し、そのユーザーをsystem:mastersグループに紐付ければ、そのIAMユーザーがクラスタを操作できるようになる、と説明されています。
しかし、system:mastersグループってなんや？って思いませんか？
上記ページでは
クラスターの RBAC 設定で system:masters のアクセス許可が自動的に付与されます
と書かれているのみでsystem:mastersってなんや？
という問いには答えてくれません。
今日はその
system:mastersってなんや？
について書いてみようと思います。
system:mastersグループってなんや？
このグループ一体どこで詳細が見えるんでしょうかね？
https://stackoverflow.com/questions/51612976/how-to-view-members-of-subject-with-group-kind
上記URLを参考にしてコマンドを実行してみます。
» kubectl get clusterrolebindings -o json | jq -r '.items[] | select(.subjects[0].kind=="Group") | select(.subjects[0].name=="system:masters")'
{
"apiVersion": "rbac.authorization.k8s.io/v1",
"kind": "ClusterRoleBinding",
"metadata": {
"annotations": {
"rbac.authorization.kubernetes.io/autoupdate": "true"
},
"creationTimestamp": "2019-04-05T02:44:54Z",
"labels": {
"kubernetes.io/bootstrapping": "rbac-defaults"
},
"name": "cluster-admin",
"resourceVersion": "94",
"selfLink": "/apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin",
"uid": "caf684e8-574c-11e9-b562-06cc5b913a28"
},
"roleRef": {
"apiGroup": "rbac.authorization.k8s.io",
"kind": "ClusterRole",
"name": "cluster-admin"
},
"subjects": [
{
"apiGroup": "rbac.authorization.k8s.io",
"kind": "Group",
"name": "system:masters"
}
]
}
subjectsの中にsystem:mastersグループが含まれているのがわかります。
上記コマンドではjqコマンドでkubectl get clusterrolebindingsの出力からkindがGroupでnameがsystem:mastersの出力を切り出していますが、ClusterRoleBindingとしてのエントリは一つだけで、それが、cluster-adminというClusterRoleとsystem:mastersというGroupをバインド（紐付け）していることがわかります。
さきほどのConfigMapでは、指定したユーザーをsystem:mastersグループに追加することで、このClusterRoleBindingを通して、そのユーザーにcluster-adminロールが付与されることになります。
では、cluster-adminには何ができるか？
» kubectl get clusterrole cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
creationTimestamp: "2019-04-05T02:44:53Z"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-admin
resourceVersion: "41"
selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/cluster-admin
uid: ca8fef87-574c-11e9-b562-06cc5b913a28
rules:
- apiGroups:
- '*'
resources:
- '*'
verbs:
- '*'
- nonResourceURLs:
- '*'
verbs:
- '*'
rulesのところを見ると全部の項目が*になってますね。
https://kubernetes.io/docs/reference/access-authn-authz/rbac/
上記に書かれたClusterRoleのサンプルが以下です。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
#
# at the HTTP level, the name of the resource for accessing Secret
# objects is "secrets"
resources: ["secrets"]
verbs: ["get", "watch", "list"]
この場合は、secretsに対するread権限を持つロールが定義されているという意味ですが、cluster-adminの場合は、全てのリソースに対して全ての操作が許可されている、ということがわかるかと思います。
じゃ、Groupはどうやって見るの？
さきほど、kubectlからsystem:mastersの情報を取得するコマンドの出力を掲載しましたが、それはClusterRoleBindingの出力から取り出しています。
ClusterRoleBindingじゃなくて、Groupから取り出せばいいんじゃないの？と思うかもしれません。
しかし、
» kubectl api-resources
NAME SHORTNAMES APIGROUP NAMESPACED KIND
bindings true Binding
componentstatuses cs false ComponentStatus
configmaps cm true ConfigMap
endpoints ep true Endpoints
events ev true Event
limitranges limits true LimitRange
namespaces ns false Namespace
nodes no false Node
persistentvolumeclaims pvc true PersistentVolumeClaim
persistentvolumes pv false PersistentVolume
pods po true Pod
podtemplates true PodTemplate
replicationcontrollers rc true ReplicationController
resourcequotas quota true ResourceQuota
secrets true Secret
serviceaccounts sa true ServiceAccount
services svc true Service
mutatingwebhookconfigurations admissionregistration.k8s.io false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io false ValidatingWebhookConfiguration
customresourcedefinitions crd,crds apiextensions.k8s.io false CustomResourceDefinition
apiservices apiregistration.k8s.io false APIService
controllerrevisions apps true ControllerRevision
daemonsets ds apps true DaemonSet
deployments deploy apps true Deployment
replicasets rs apps true ReplicaSet
statefulsets sts apps true StatefulSet
tokenreviews authentication.k8s.io false TokenReview
localsubjectaccessreviews authorization.k8s.io true LocalSubjectAccessReview
selfsubjectaccessreviews authorization.k8s.io false SelfSubjectAccessReview
selfsubjectrulesreviews authorization.k8s.io false SelfSubjectRulesReview
subjectaccessreviews authorization.k8s.io false SubjectAccessReview
horizontalpodautoscalers hpa autoscaling true HorizontalPodAutoscaler
cronjobs cj batch true CronJob
jobs batch true Job
certificatesigningrequests csr certificates.k8s.io false CertificateSigningRequest
leases coordination.k8s.io true Lease
eniconfigs crd.k8s.amazonaws.com false ENIConfig
events ev events.k8s.io true Event
daemonsets ds extensions true DaemonSet
deployments deploy extensions true Deployment
ingresses ing extensions true Ingress
networkpolicies netpol extensions true NetworkPolicy
podsecuritypolicies psp extensions false PodSecurityPolicy
replicasets rs extensions true ReplicaSet
ingresses ing networking.k8s.io true Ingress
networkpolicies netpol networking.k8s.io true NetworkPolicy
runtimeclasses node.k8s.io false RuntimeClass
poddisruptionbudgets pdb policy true PodDisruptionBudget
podsecuritypolicies psp policy false PodSecurityPolicy
clusterrolebindings rbac.authorization.k8s.io false ClusterRoleBinding
clusterroles rbac.authorization.k8s.io false ClusterRole
rolebindings rbac.authorization.k8s.io true RoleBinding
roles rbac.authorization.k8s.io true Role
priorityclasses pc scheduling.k8s.io false PriorityClass
csidrivers storage.k8s.io false CSIDriver
csinodes storage.k8s.io false CSINode
storageclasses sc storage.k8s.io false StorageClass
volumeattachments storage.k8s.io false VolumeAttachment
APIリソースのどこにもgroupsは存在しません。
そうなんです。
https://stackoverflow.com/questions/51612976/how-to-view-members-of-subject-with-group-kind
にも記載されていますが、kubectlにはGroupをリストアップしたり詳細を表示したりするインターフェースはありません。
さきほどConfigMapにmapUsersとして登録したユーザーも同様です。
こうしたインターフェースがなぜないのか？についてまではちょっと調べられませんでしたが、上記でユーザーをsystem:mastersグループに追加するとなぜクラスタを操作できるようになるかはご理解いただけたのではないかと思います。