kubernetesがkubectlをどのように権限管理するか

ターゲット
カスタムkubectlは、k 8 sリソースの権限を操作できます.たとえば、すべてのリソースに対して読み取りのみ、削除変更はできません.
基本的な知識
kubernetes自体はRBAC権限チェックをサポートしており、現在の主流バージョンではデフォルトでサポートされており、デフォルトでオープンしています.apiserverの構成を確認して、自分のk 8 sがサポートされているかどうかを見ることもできます.
我々がkubectlに対する権限管理を実現するには、k 8 sのRBACに依存しなければならない.kubectlのデフォルトでは、読み出し~/.kube/configファイルは構成としてk 8 sのapiserverと通信しているので、問題の鍵の一つは、このプロファイルをどのように生成するかです.
k 8 sのRBACは4つのリソースオブジェクトを定義した:Role、ClusterRole;Rolebinding、ClusterRoleBinding、そのうち:
Role:権限の集合を定義します.注意してください.RoleはName paceの下に定義されています.
ClusterRole:Roleと似ていますが、クラスタ全体で使用されており、ネーミングスペースの束縛はありません.
RoleBinding:RoleをSubjectにバインドし、Role定義のすべての権限をSubjectに統合できるようにするためです.
ClusterRoleBinding:RoleBindingとはあまり差がありませんが、ClusterRoleをSubjectにバインドしています.
では、Subjectとは何ですか.Subjectは実は“ユーザー”と理解することができて、それはいくつかの種類があって、それぞれ:User、Group、ServiceAccount、私達は直接ソースコードを通じてSubjectの定義を見ます(注釈を重視します!!)

// Subject contains a reference to the object or user identities a role binding applies to. This can either hold a direct API object reference,
// or a value for non-objects such as user and group names.
type Subject struct {
// Kind of object being referenced. Values defined by this API group are "User", "Group", and "ServiceAccount".
// If the Authorizer does not recognized the kind value, the Authorizer should report an error.
Kind string `json:"kind" protobuf:"bytes,1,opt,name=kind"`
// APIGroup holds the API group of the referenced subject.
// Defaults to "" for ServiceAccount subjects.
// Defaults to "rbac.authorization.k8s.io" for User and Group subjects.
// +optional
APIGroup string `json:"apiGroup,omitempty" protobuf:"bytes,2,opt.name=apiGroup"`
// Name of the object being referenced.
Name string `json:"name" protobuf:"bytes,3,opt,name=name"`
// Namespace of the referenced object. If the object kind is non-namespace, such as "User" or "Group", and this value is not empty
// the Authorizer should report an error.
// +optional
Namespace string `json:"namespace,omitempty" protobuf:"bytes,4,opt,name=namespace"`
}

では、Subjectはどこですか.RoleまたはClusterRoleをバインドするには、RoleBindingまたはClusterRoleBindingを構成する必要があります.そのため、SubjectはRoleBindingまたはClusterRoleBindingにあります.以下、実操手順を行います.
インプリメンテーション
1、ClusterRoleを作成する
読み取り専用リソースのアクションを定義します.まず、ファイルclusterrole-mytest-viewを作成します.yaml、内容は以下の通りです.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  name: mytest-view
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  - endpoints
  - persistentvolumeclaims
  - pods
  - replicationcontrollers
  - replicationcontrollers/scale
  - serviceaccounts
  - services
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - bindings
  - events
  - limitranges
  - namespaces/status
  - pods/log
  - pods/exec
  - pods/status
  - replicationcontrollers/status
  - resourcequotas
  - resourcequotas/status
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - pods/exec
  verbs:
  - create
- apiGroups:
  - apps
  resources:
  - daemonsets
  - deployments
  - deployments/scale
  - replicasets
  - replicasets/scale
  - statefulsets
  - statefulsets/scale
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - batch
  resources:
  - cronjobs
  - jobs
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions
  resources:
  - daemonsets
  - deployments
  - deployments/scale
  - ingresses
  - networkpolicies
  - replicasets
  - replicasets/scale
  - replicationcontrollers/scale
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - networkpolicies
  verbs:
  - get
  - list
  - watch

2、ServiceAccountの作成
このステップを経ると、実際にSecretリソースがあります.これは、ServiceAccountを作成すると、k 8 sが自動的にSecretリソースを作成し、Secretリソースには、必要な証明書などの情報があるからです.

kubectl create ns mytest
kubectl create sa -n mytest user-guest

3、ClusterRoleBindingを作成し、ClusterRoleの権限をServiceAccount作成ファイルclusterrolebinding-viewにバインドする.yml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: mytest:user-guest
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: mytest-view
subjects:
- kind: ServiceAccount
name: user-guest
namespace: mytest

コマンドの実行、リソースの作成

kubectl apply -f clusterrolebinding-view.yml

4、構成を生成する:guest.config

TOKEN=$(kubectl get sa -n mytest user-guest -o go-template='{{range .secrets}}{{.name}}{{end}}')
echo $TOKEN
CA_CERT=$(kubectl get secret -n mytest ${TOKEN} -o yaml | awk '/ca.crt:/{print $2}')
echo $CA_CERT

#     ，      apiserver   
API_SERVER="https://172.1.3.17:6443"
echo $API_SERVER

cat < guest.config
apiVersion: v1
kind: Config
clusters:
- cluster:
certificate-authority-data: $CA_CERT
server: $API_SERVER
name: cluster
EOF

5、guestを更新する.config構成

SECRET=$(kubectl -n mytest get secret ${TOKEN} -o go-template='{{.data.token}}')
kubectl config set-credentials mytest-guest --token=`echo ${SECRET} | base64 -d` --kubeconfig=guest.config
kubectl config set-context default --cluster=cluster --user=mytest-guest --kubeconfig=guest.config
kubectl config use-context default --kubeconfig=guest.config

6、guest.config、名前を変更した後、~/.kubeディレクトリの下でいいです.