[单master节点k8s部署]15.安全机制

用户访问集群需要认证、授权、准入三个步骤。apiserver是整个集群访问控制的唯一入口。

认证

认证是对用户的身份认证，通常包括用户名密码认证，但是也包括对service account的认证。

限制不同用户访问集群

生成ssl密钥

在/etc/kubernetes/pki/ 目录中，生成用户访问的密钥，首先生成一个集群上的私钥，用以下命令：

(umask 077; openssl genrsa -out lucky.key 2048)

这是生成一个私钥，并保存到lucky.key中，但是相应的公钥也可以从私钥中获取

openssl rsa -in lucky.key -pubout -out lucky.pub

然后生成一个rsa请求，这个请求可以向ca机构请求一个ca证书，从而加密自己的私钥。用以下命令：这里是生成一个针对私钥lucky.key的ca证书的请求，然后把它保存为lucky.csr,并且指定csr的主题信息为通用名称(common name)=lucky

openssl req -new -key lucky.key -out lucky.csr -subj "/CN=lucky"

然后使用在集群中有的ca证书（ca.crt,ca.key）来生成ca签名过的包含公钥的文件。

openssl x509 -req -in lucky.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out lucky.crt -days 3650

[root@master pki]# ls
apiserver.crt              apiserver-etcd-client.key  apiserver-kubelet-client.crt  ca.crt  ca.srl  front-proxy-ca.crt  front-proxy-client.crt  lucky.crt  lucky.key  sa.pub
apiserver-etcd-client.crt  apiserver.key              apiserver-kubelet-client.key  ca.key  etcd    front-proxy-ca.key  front-proxy-client.key  lucky.csr  sa.key

加入用户

将lucky用户加入集群用户里面，在此目录下运行：

 kubectl config set-credentials lucky --client-certificate=./lucky.crt --client-key=./lucky.key --embed-certs=true

然后查看/etc/.kube/config文件，可以看到lucky的用户被添加到config文件中

[root@master .kube]# cat config 
apiVersion: v1
clusters:
- cluster:
   ...
- name: lucky
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvVENDQVlrQ0NRRFNTZ3Fyam51R1pqQU5CZ2txaGtpRzl3MEJBUXNGQURBVk1STXdFUVlEVlFRREV3cHIKZFdKbGNtNWxkR1Z6TUI0WERUSTBNRGN3TWpBME16STBPVm9YRFRNME1EWXpNREEwTXpJME9Wb3dFREVPTUF3RwpBMVVFQXd3RmJIVmphM2t3Z2dFaU1BMEdDU3FHU0liM0RRRUJBUVVBQTRJQkR3QXdnZ0VLQW9JQkFRQzZ6cVVqCnZSaG1vZFJjUnNHZnVCeENvNS9nTnVOLzdLUkdjcVhSWGZKU01GaUQ1TmU1WUNzeW03TlAzKzRMMmg5OGFvRm4KNk9sNTM4NGFISlpXVlhEdTFMSmFIR0ZmdXNSMk13aGlYR0VyNnN5Z2UyRlFLT2FIM2tEbForbEpjQkNtWS9LRgpmZHI0eHpYMGExU3ZDMEovSkZlNWk0UCswd2IwdEY5U0lLeE5aaUJCbDNiQ1VWeTVsR24waXB0WUlpclRkRFlMCjIvd0tIcFZadHRZMjdCVGhwNE1NU1hkTC9qK1dhRGFnVHVKbWdyZGhwK3pHMlJoenFSTGp3bTBsUWRsY0tVTjAKZFNLWERnWU9UOHpEN3dtS0lYYmFid0FLSWtpVFNaeEFKN1UwRXRNV29ieEp6eURybHRKSUdBYkF5UjNBOGJZOApKaWdscmxiODhhMFVQQXVSQWdNQkFBRXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBRXhwV1ZITXB6TlBtZEhqClhBNFQ3UDl0dkxmNWZwUzQyWFZyUHZjRmt0WnUzeno1KzhxZ1UvYnhuVWppRDhnUjFhVHMwQllGT3BGeitqYXYKTzBybzU4R3k0OGFmb1U5MENEL2dGL21JalBjYmtnb01VeUR6alUzdkUrMUxZc3VRWUlGTkV0VnBibTJ4VjVYaAp4cUtiUG5oN3JjVG9nb2hwYVhOT0Q0RTErYU1RUm85VWtndFludVZiOHlacFlvTktJekRNWDhiYTE1RWoxbUFkCmVLUFJPSEw0Z0pvaGVkSW1PcGJyWlN1byt4SWhRUmpCSXBuZ1hCcjl5bkpUUmdKRzlPOTlobG1IMEVqd1VzMHkKQVZLbXVsMnRHNFRlYktGWmRXNFdRRHhMVmRaTlFNRGRjRzMyQnFBeW9rWHl2R2oxNWxyb3d2c3pwNy83dW5DRwpPbDhiRnVvPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFcEFJQkFBS0NBUUVBdXM2bEk3MFlacUhVWEViQm43Z2NRcU9mNERiamYreWtSbktsMFYzeVVqQllnK1RYCnVXQXJNcHV6VDkvdUM5b2ZmR3FCWitqcGVkL09HaHlXVmxWdzd0U3lXaHhoWDdyRWRqTUlZbHhoSytyTW9IdGgKVUNqbWg5NUE1V2ZwU1hBUXBtUHloWDNhK01jMTlHdFVyd3RDZnlSWHVZdUQvdE1HOUxSZlVpQ3NUV1lnUVpkMgp3bEZjdVpScDlJcWJXQ0lxMDNRMkM5djhDaDZWV2JiV051d1U0YWVEREVsM1MvNC9sbWcyb0U3aVpvSzNZYWZzCnh0a1ljNmtTNDhKdEpVSFpYQ2xEZEhVaWx3NEdEay9Ndys4SmlpRjIybThBQ2lKSWswbWNRQ2UxTkJMVEZxRzgKU2M4ZzY1YlNTQmdHd01rZHdQRzJQQ1lvSmE1Vy9QR3RGRHdMa1FJREFRQUJBb0lCQVFDb0d3M0ErNG5aMGdlbwpnb1A3bDFMWEpTZmFQWXE4czllaERjcnFmZ0J5dGM3eDRoMi9WQ3VMZjFIOXJ5WW94RUZSVlFiZTIxby9zb2RtCk9CT1IzWkdqV3dTazBxVk40R1NyZVlFeUFxL3ZOWHl2YmxoRUtvcEorbGVzR2JaMXY4TTcrUFZsNjd3QjVFTkoKa016RU9QMitMSlpGQXFmbHlVR1pORGdUVUJPK0VYeHhqZERlRyswUE1TL0NzSmYvaGZQTlB6NEhuVmEydWhyZwppNEczcVE3NDNwL1ExZGwzU0ppTEFTSkh6eHd0OG1BRWJQWDZxcHJHVGQyQzlvT0J3MW8ra085dDc4RFB1eDU3CkZhcFVtMk9yb1MweCt3Nng3WnhqQmpLSUp1Y3hKNHZ4QkVjbTBoRlJtMnBiaVRNZERGN1ZBOVBhZ2RCdkQ4TzMKKzVVQzg4QUJBb0dCQVBoS3dtNnErSTRmNjlZaEpjeU5nNTlBRmJlNng3bTJuenVaY1Q1UUM0eXlNWUZNVllRLwoyeW55R1NsMXhaN3BDbTA2ZWpTNmVEWDNHeUZPVlc1TW5WYjE4dUo5aklUYTlmcG1Kazg5TTlVNFQ5OWVDWjBXCnBHa2lkaEpTV01QVlFDaitaa3g0eDZzeTdjc1pqTVl3d0JubTlScnBqMExNVVlodnIzRENTWWxoQW9HQkFNQ2IKUC9vbUozS1krTHJGZ0hrRWpSa3NvdXlUb2wxMjJFL0Y4Rzkza1hlQ01FOE5YZ2IrR1VybFYrSTB2VlhXbFVLTgpvaVVPQ3ZMeFZjOVhIQ0FUN01HN0xGRWlZNTc4czdIM3FxWERpOThrR1NpT3NnNy9MUGYwVzI2a043K3RZT29wCllzZlZYVllzbHZ6eE05RnBqNkdBWWRSSHpMNCthZzlpNVdReElNQXhBb0dBUjliSm50K1Uvdm81Y0VFekFKWkoKYVFCUHlGTWdpcGxPUlI1R1o3TWRSRjRpZUxpdlhZNWtTU1NsSnh2T1RBWTlZQkUxWHFBOU84LzlaNHVVcUU4KwpqdlNtaStXcmpKMFY0cGMvcWxtWTc2NVZYZG1GaXBBTWplYk1wc3h3cG1qRElabEozQUp1TXhpUE9ONXhucjVvCk5wWmVnS1RuTUhxUmRKcHI5b0lnYU1FQ2dZQU11blhJNXpxV0pTdlMwL2lBaHQ5NE9XM3U2bmJCYkhneEZXaWwKUlNhVTJrS3RCcm9mQmkzUHVFWk5pYVMxaG4vSXJTbDQvMnVUMElVV05iQ0RJaTMwUTVWVEswMmdGUjBlOXJvTgpTRlgzQWlDemdIS2Q4UmtjcmNaWkVuc29yS0dKK0FBeUtwU0hmRnppREdLYlJUbWJ0NnMvWnh0TnV6d3hGaDBJCnVRSnNFUUtCZ1FEUk92WlFkaDhxcUJrZ0VrSzhXcEs5Skg4L29abGhhUzBseE9IcUptN1M4TkRCbU1hQWNxdUQKK2RxRGxnQmdUNHVNM3dmMmsrRU55azR1bktVbWV2czBHbEZ4dmJzTTlBdHJLQ3hLTG1KQ25RS2tFNXNnRStKZQpRZXZ0REFoRVFJYWttRmNuUFlnZ2Zzd2toYmRycU00OTZjam5uV2FEK2MxTzJNbmJEQXdFVHc9PQotLS0tLUVORCBSU0EgUFJJVkFURSBLRVktLS0tLQo=

切换上下文为用户lucky，然后执行kubectl get 命令，发现没有权限，这是因为用户创建以后还没有绑定任何rbac权限。

[root@master]# kubectl config set-context lucky@kubernetes --cluster=kubernetes --user=lucky
[root@master]# kubectl config use-context lucky@kubernetes
Switched to context "lucky@kubernetes".
[root@master]# kubectl get pods
Error from server (Forbidden): pods is forbidden: User "lucky" cannot list resource "pods" in API group "" in the namespace "default"

绑定授权

创建namespace，并且把它绑定到用户上，让该用户只能操作lucky 命名空间下的资源

kubectl create ns lucky
kubectl create rolebinding lucky -n lucky --clusterrole=cluster-admin --user=lucky

serviceAccount

service account是为了方便pod里面的进程调用kubernetes API或其他外部服务而设计的，是为pod设计的。每个pod在创建后，都会自动设置spec.serviceAccount为default，除非制定了service Account。

以12.持久化存储中的nfs provisioner为例，创建的pod就标明了 serviceAccount: nfs-provisioner

[root@master nfs]# cat nfs-deployment.yaml 
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-provisioner
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-provisioner
  strategy: 
    type: Recreate
  template:
    metadata:
      labels:
        app: nfs-provisioner
    spec:
      serviceAccount: nfs-provisioner
      containers:
      - name: nfs-provisioner
        image: registry.cn-beijing.aliyuncs.com/mydlq/nfs-subdir-external-provisioner:v4.0.0
        imagePullPolicy: IfNotPresent
        volumeMounts:
        - name: nfs-client-root
          mountPath: /persistentVolumes
        env:
        - name: PROVISIONER_NAME
          value: example.com/nfs
        - name: NFS_SERVER
          value: 100.64.252.90
        - name: NFS_PATH
          value: /data/nfs_pro
      volumes:
      - name: nfs-client-root
        nfs:
          path: /data/nfs_pro
          server: 100.64.252.90

同时这个serviceAccount也是提前定义好的

apiVersion: v1
kind: ServiceAccount
metadata: 
  name: nfs-provisioner

创建sa的时候会自动的创建一个token，保存在secret里面。查看集群里面的sa，可以发现有一个刚才创建的，还有一个命名空间自己的default的service account，这是因为在 my-namespace 中创建一个 Pod，而没有指定 ServiceAccount 时，Pod 会自动使用 default ServiceAccount，这个 Pod 会自动使用 my-namespace 中 default ServiceAccount 的 Token，该 Token 存储在 default-token-abcde Secret 中，并被自动挂载到 Pod 的文件系统中，从而让pod有一定的权限。

[root@master yam_files]# kubectl get sa
NAME              SECRETS   AGE
default           1         16d
nfs-provisioner   1         32h
[root@master yam_files]# kubectl get secret
NAME                          TYPE                                  DATA   AGE
default-token-sqbqc           kubernetes.io/service-account-token   3      16d
nfs-provisioner-token-wgfv4   kubernetes.io/service-account-token   3      32h

[root@master yam_files]# kubectl get secret default-token-sqbqc -o yaml 
apiVersion: v1
data:
  ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJME1EWXhOVEV5TXpRME9Gb1hEVE0wTURZeE16RXlNelEwT0Zvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTGF2Cm14R3VLeXFZTzhkVVdSVWEyNDR2TE1WM3hvcnpTa04xdGV0RHJtRXJpSkxKZmRVdWRVTDBPYVIzTzFIR1QrZG4KMTNQZStock85QzVuV1kyRWJpMU54bTFKSnVNclZlbThwcURpZnhpNTZ0QnhYRWJPNTQrL1lrSi80cG5MS1I2egpudTZTZElxQ1E4aFVNeFVnL2FIczNuMHE2cjFqWTNxZTArNDhza0hMVWpNbmxmdkp0UDhPaWNNa3ZEaHI4OEJxCjNQVXZGRGl6ZTdBVkVPbzZWOFVhdEp4MkFZOEsySE5rV0YyeWsvTC9MUHh2V3ZwTFRKcTdXcCtJZGdIQVFjUDgKRjVDNm1WQmpsQjZCejVjMnhSN2c5V0g4blJ3aExUMlhURDk5WGpkU0liOWlpblNDdGp5VnMwM0I1SVhWaCtjLwpROHpOa0Rrc2tYaXJOb0Q5anlVQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJZRUZNbThFTFlSZnUzNmJ0b29CVGlGbk5MR0M5V25NQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBS2RncGRWeVJvYm5oeUlGZmE1aApUeW0rRk5RUW52WTVqYzZXWEc1RktVMkNCWGE3TGg2NEFnUHNxL2RHemFHL2pEMUNpM1liaU9KTHpFeGR0RFJCCk9ZemZIUjE0SUZGd3VuS1hiOVNHT09CL3gwWFpVSUtsQk5oWWdwSFdIUUtqZ2N1bzZFQWVxSEV0ekZBVStLdmsKcHhVS3o1V2JSNlovUitzVC92YUoyODRkWEpZcXV0NExORThWNi9VZ25lNUtjeHppQjFlTitmMytNVzh3djNINAp6cExsbVhER1htcThCTEgwaEhSeS92cGc2UUFwMDA4bXZwNWtlY2h3SHNlYjkxVTJSVFd6V0pVWCtobHY3bkFPCkc4QjZKRzRlU2Y4cXBLNEE5UDlGaTUvSzFtWXoyRzB6MFM3T2FNY1B6aVp4dm10KzhDR0NBMVphUjVUeldta3cKRDQwPQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
  namespace: ZGVmYXVsdA==
  token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJbXRwWkNJNkltb3pSR1pVWTNaVWVIbDNMVzlTWTNjNFNVZE1Temx5Y1ZGeWJXRkxMVk15T0ZaUlJWYzJURU50V1hNaWZRLmV5SnBjM01pT2lKcmRXSmxjbTVsZEdWekwzTmxjblpwWTJWaFkyTnZkVzUwSWl3aWEzVmlaWEp1WlhSbGN5NXBieTl6WlhKMmFXTmxZV05qYjNWdWRDOXVZVzFsYzNCaFkyVWlPaUprWldaaGRXeDBJaXdpYTNWaVpYSnVaWFJsY3k1cGJ5OXpaWEoyYVdObFlXTmpiM1Z1ZEM5elpXTnlaWFF1Ym1GdFpTSTZJbVJsWm1GMWJIUXRkRzlyWlc0dGMzRmljV01pTENKcmRXSmxjbTVsZEdWekxtbHZMM05sY25acFkyVmhZMk52ZFc1MEwzTmxjblpwWTJVdFlXTmpiM1Z1ZEM1dVlXMWxJam9pWkdWbVlYVnNkQ0lzSW10MVltVnlibVYwWlhNdWFXOHZjMlZ5ZG1salpXRmpZMjkxYm5RdmMyVnlkbWxqWlMxaFkyTnZkVzUwTG5WcFpDSTZJbU0xTkRZelltUmlMVFl6TlRVdE5HSXhPUzA0Tm1WakxUY3haR0ZsT1RobU9HSTJNeUlzSW5OMVlpSTZJbk41YzNSbGJUcHpaWEoyYVdObFlXTmpiM1Z1ZERwa1pXWmhkV3gwT21SbFptRjFiSFFpZlEuS1BaM2poWkhwWjc1Uzg4U1pKZHk4RWJBZFlxZ2NXMFBfQnVBOVFIMTBhVGI0VjZDWHp5RWFNb0ZweDJPc3FZQ3dEWjh1UlpaZG5BeDB3emgwNkpHWUtOUGJiNGJDcVJDcVBWVVpuSTktNlRsNjlvT0xVOGJ3V1F3alM5Z2I5eE1aMlNpRGZPOXFtbDFzdDhxc2dXaTZYVmpfR24tNlRHd0NPeDVxT2ZYanB5a2NDTmdXWVlISmFZUEtYdkIzOWtlUklqMVlKNGVNUXNIRmlJVHhIR19zMVBHQTkyZHdsY3liZjlaTE1qMnFiTG5qZEQ4ZzNKeXB0eUJuVElGTUZDaHkxQlB4djVCLW1mOTRMYU5pRmJiU19TTEpKNGI1TFRQYUk2RlNyVjMzR1hsblRQbnM5R0NJZ1VrelRxc3d2ZXdhSk9WdWI5dDBVZ240SWk4bDFYWklR
kind: Secret
metadata:
  annotations:
    kubernetes.io/service-account.name: default
    kubernetes.io/service-account.uid: c5463bdb-6355-4b19-86ec-71dae98f8b63
  creationTimestamp: "2024-06-15T12:35:13Z"
  name: default-token-sqbqc
  namespace: default
  resourceVersion: "425"
  uid: ee7d82cb-4af1-4949-8faa-367962bcea26
type: kubernetes.io/service-account-token

每一个用于aservice account的secret其实都有一个token和ca证书。

授权

对资源进行授权，授权检查机制回根据授权规则判定该资源是否是该用户可以访问的。k8s的授权是基于插件形成的，其常用的授权插件有以下几种：

1.node节点认证

2.ABAC基于属性的访问控制

3.RBAC基于角色的访问控制

4.webhook基于http回调机制的访问控制

其中RBAC是最常用的授权机制，把用户和角色绑定，从而赋予权限

以12中的nfs 供应商为例，在上面创建sa后，默认情况下，ServiceAccount 的权限非常有限。如果没有为 ServiceAccount 绑定任何 Role 或 ClusterRole，它将无法执行大多数操作，尤其是跨命名空间或集群范围的操作。例如：

它无法在其他命名空间中创建、修改或删除资源。
它无法获取集群范围的资源（如节点信息）。
它只能执行一些基本的读取操作。

所以创建了一个clusterrolebinding，是对整个集群有效，针对的是clusterrole。相对的还有rolebinding，只对rolebinding所在的命名空间有效。

以下命令将 cluster-admin ClusterRole 绑定到 default 命名空间中的 nfs-provisioner 的ServiceAccount，从而赋予了这个sa权限。

kubectl create clusterrolebinding nfs-provisioner-clusterrolebinding --clusterrole=cluster-admin --serviceaccount=default:nfs-provisioner

RBAC

RBAC有四种资源，role，cluster role，rolebinding，clusterrolebinding

apiGroups

Kubernetes API 由不同的 API 组和版本组成，每个组包含一组相关的资源。比如：

核心api组：apiGroups: [""]，资源：Pod、Service、ConfigMap、Secret、Node、Namespace 等。 API 版本：v1

apiGroups: ["apps"],资源：Deployment、DaemonSet、StatefulSet、ReplicaSet。API 版本：apps/v1

apiGroups: ["batch"]，资源：Job、CronJob。 API 版本：batch/v

apiGroups: ["autoscaling"]，资源：HorizontalPodAutoscaler。API 版本：autoscaling/v1

1.role

创建一个角色，针对核心api组进行pod的角色授权。

apiVersion：rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: rbac
  namespace: pod-read
rules:
  - apiGroups: [""]
    resources: ["pods"]
    resourceNames: []
    verbs: ["get","watch","list"]

2.clusterRole

创建对整个secret的集群操作角色

如果是对某些资源的某些名称的资源进行操作，还可以在resource name里面进行标注

apiVersion: rbac.authorization.k8s.io/v1
kind: clusterRole
metadata:
  name: secret-clusterrole
  namespace: rbac
rules:
  apiGroups: [""]
  resourceNames: []
  resources: ["secrets"]
  verbs: ["get","watch","list"]

3.rolebinding

以下是两种rolebinding，一种是绑定了上文中创建的pod-read的角色，另一种是绑定了集群中已经存在的cluster role，但是仅仅在规定的命名空间中使用。

[root@master role]# cat rolebinding1.yaml 
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
 name: rolebinding_1
 namespace: rbac
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role 
  name: read-pod
subjects:
- kind: User
  name: user
  apiGroup: rbac.authorization.k8s.io
[root@master role]# cat rolebinding_2.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: all-resource
  namespace: rbac
subjects:
- kind: User
  name: user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin

绑定成功

[root@master role]# kubectl get rolebinding -n rbac
NAME            ROLE                        AGE
all-resource    ClusterRole/cluster-admin   6s
rolebinding_1   Role/read-pod               5m1s

4.cluster rolebinding

apiVersion:  rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-binding1
roleRef:
  name: secret-clusterrole
  kind: ClusterRole
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: deployment
  kind: Group
  apiGroup: rbac.authorization.k8s.io

绑定成功。

[root@master role]# kubectl get clusterrolebinding
NAME                                                   ROLE                                                                               AGE
calico-kube-controllers                                ClusterRole/calico-kube-controllers                                                16d
calico-node                                            ClusterRole/calico-node                                                            16d
cluster-admin                                          ClusterRole/cluster-admin                                                          16d
cluster-binding1                                       ClusterRole/secret-clusterrole                                                     16s
...

特殊群组的授权

（1）qa 命名空间中的所有 Service Account：
subjects:
- kind: Group
 name: system:serviceaccounts:qa
 apiGroup: rbac.authorization.k8s.io
（2）所有 Service Account
subjects:
- kind: Group
 name: system:serviceaccounts
 apiGroup: rbac.authorization.k8s.io 
（3）所有认证用户
subjects:
- kind: Group
 name: system:authenticated
 apiGroup: rbac.authorization.k8s.io 
（4）所有未认证用户
subjects:
- kind: Group
 name: system:unauthenticated
 apiGroup: rbac.authorization.k8s.io
（5）全部用户
subjects:
- kind: Group
 name: system:authenticated
 apiGroup: rbac.authorization.k8s.io
- kind: Group
 name: system:unauthenticated
 apiGroup: rbac.authorization.k8s.io

就是说，如果要给所有serviceAccount一个权限角色，可以使用 system:serviceaccounts这个名称

kubectl create clusterrolebinding aa --clusterrole=view --group=system:serviceaccounts

如果给某一个命名空间下的所有serviceAccout都加一个权限角色，需要标明namespace

--clusterrole=view：指定使用预定义的 ClusterRole 名为 view，这个 ClusterRole 通常包含了查看大部分资源但不包括写权限的能力。

kubectl create rolebinding bb --clusterrole=view --group=system:serviceaccounts:my-namespace --namespace=my-namespace

为一个命名空间中名为 default 的 Service Account 授权，因为没有写明service Account的pod的默认service account都是default。

kubectl create rolebinding default-view --clusterrole=view --serviceaccount=my-namespace:default --namespace=my-namespace

与service Account绑定

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pod-sa
roleRef:
  name: read-pod
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
subjects:
- name: read-pod-sa
  kind: ServiceAccount
  apiGroup: rbac.authorization.k8s.io

准入

准入控制器位于api server中，有两种，第一是变更（Mutating）准入控制：修改请求的对象。第二是验证（Validating）准入控制：验证请求的对象。准入控制（Admission Control）是 Kubernetes 中的一种机制，用于在请求到达 API 服务器后但在其持久化之前（持久化是指将资源对象（如 Pod、Service、ConfigMap 等）保存到集群的持久存储中），对请求进行拦截和处理。准入控制器可以对请求进行修改（变更）或验证（验证），确保集群的安全性和策略一致性。

如果没有准入控制的话集群就是在裸奔，kube-apiserver 是 Kubernetes 集群的网关，所有的请求都需要通过它来访问集群。它提供了一个 RESTful API 接口，通过这个接口，用户、开发者、运维人员以及 Kubernetes 内部组件都可以与集群进行交互。

准入控制是为了定义我们授权检查完成之后的其他安全操作的，进一步补充了授权机制，一般在创建、删除修改或者做代理的时候做补充。

k8s的准入控制其实是一个准入控制插件的列表，发送到APIserver的请求都需要通过这个列表中的每个准入控制插件的检查，如果某一个控制器插件准入失败，就准入失败。

练习：

在命名空间 rbac 中为名为 myapp 的 Service Account 授予 view ClusterRole：

在全集群范围内为用户 root 授予 cluster-admin ClusterRole：

在全集群范围内为名为 myapp 的 Service Account 授予 view ClusterRole：

kubectl create rolebinding aa --clusterrole=view --serviceAccount=rbac:myapp --namespace=rbac
kubectl create clusterrolebinding bb --clusterrole=cluser-admin --user=root
kubectl create clusterrolebinding aa --clusterrole=view --serviceAccount=system:serviceaccounts:myapp