kube-api-server authorization(RBAC)

起動オプションとして --authorization-mode
を渡すことができて RBAC 以外にも ABAC、Webhook 等が選択できる

EKS だと Node,RBAC,Webhook
が渡されてる。認証モードは EKS API と ConfigMap
を設定(多分 EKS API Only でも同じ設定な気がする。ConfigMap Only があった時代は RBAC だけでも良かったはず)(Node はなんであるのか不明)
❯ aws logs get-log-events --log-group-name /aws/eks/test-cluster/cluster --log-stream-name $LOG_STREAM_NAME | jq -r '.events[].message' | grep authorization-mode
I0105 16:43:02.944275 11 flags.go:64] FLAG: --authorization-mode="[Node,RBAC,Webhook]"

全部調べるときりが無いので RBAC 前提で見ていく。
エントリはここで第二引数に authorizer.Authorizer
を指定してる

authorizer.Authorizer は Authorize() を持つインターフェースとして定義されていて、このメソッドで認可判定まで行って結果 (authorized Decision, reason string, err error)
を返す作りになっている

例えば EKS で以下のような ConfigMap を設定している場合どのように処理されるのか?
❯ k get cm aws-auth -n kube-system -oyaml
apiVersion: v1
data:
mapRoles: |
[]
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::1111111111:user/ishii
username: ishii
kind: ConfigMap

ここでユーザ情報を渡してルールマッチするか評価している
ユーザ情報の interface はこんな感じ(getUser()
という名前だが group 等も含まれている)
今回の例だと GetName() で ishii
が GetGroups() で ["system:masters"]
が返ってくるはず

ClusterRolebindings(or RoleBindings)を for 文で回して、リクエストから渡ってきたユーザ情報(aws-auth を使っている場合は case rbacv1.GroupKind:
に合致)が ClusterRolebinding の subjects.name と一致しているかをチェックしている
今回の例だと以下にマッチする
❯ k get clusterrolebindings.rbac.authorization.k8s.io cluster-admin -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
name: cluster-admin
resourceVersion: "134"
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:masters