Kubernetesのsystem:mastersグループって何？

# EKSクラスタを操作できるユーザーを追加した時の疑問
チームでEKSのクラスタを管理する場合、クラスタを作成したユーザー以外に、別途ユーザーを追加する必要が生じます。

その場合、
AWSのドキュメント「クラスターのユーザーまたは IAM ロールの管理」
https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/add-user-role.html
では、

```yaml
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を参考にしてコマンドを実行してみます。

```json
» 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`には何ができるか？

```yaml
» 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`のサンプルが以下です。

```yaml
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`グループに追加するとなぜクラスタを操作できるようになるかはご理解いただけたのではないかと思います。