Kubernetes RBAC管理
一.serviceaccount与secret
ServiceAccount为pod中的进程和外部用户提供身份信息。所有的kubernetes集群账户分为两类，kubernetes管理的serviceaccount和useraccount。
apiserver时集群的入口，对于上两者肯定时不能随便访问的，所有我们必须有一些认证信息，当他们联系apiserver的时候，他们会被认证为一个特定的ServiceAccount
1.使用默认的 ServiceAccount 访问 API server
首先我们创建一个serviceaccount服务
在1.6以上版本中，可以选择取消为ServiceAccount自动挂载API凭证，只需在ServiceAccount中设置automountServiceAccountToken:false：
apiVersion: v1
kind: ServiceAccount
metadata:
name: test-sa
automountServiceAccountToken: fakse
当你在创建pod时如果没有指定sa，系统会给你自动默认使用default下的serviceaccount
我们也可以指定serviceaccount
apiVersion: v1
kind: Pod
metadata:
name: pod-test
spec:
containers：
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
serviceAccountName: test-sa
automountServiceAccountToken: false
在1.6以上版本中，可以选择取消为ServiceAccount自动挂载API凭证，只需在ServiceAccount中设置automountServiceAccountToken:false：
创建完serviceaccount后我们可以手动创建一个新的secret
apiVersion: v1
kind: Secret
metadata:
name: test-secret
annotations:
kubernetes.io/service-account.name: test-sa
所有已经不存在的token都会被tokencontroller清理掉
# kubectl describe secrets/test-secret
Name: test-secret
Namespace: default
Labels:
Annotations: kubernetes.io/service-account.name: test
kubernetes.io/service-account.uid: cc5a5c43-4ea3-45c1-9988-366933c4248c
Type: kubernetes.io/service-account-token
RBAC
作用：
- 对集群中的资源和非资源权限均有完整的覆盖；
- 整个RBAC完全由几个API对象完成，同其他API对象一样，可以用kubectl或API进行操作；
- 可以在运行时进行调整，无需重启API Server。
要使用RBAC授权模式，需要在API Server的启动参数中加上--authorization-mode=RBAC
role与clusterrole
apiVersion： rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroup: [""]#空字符串表明使用的时core API group apigroup 可以在 api-version中做参考 使用 kubectl api-version 可以查看当前kubernetes平台下所有的api-verison
resources: ["pod"]
verbs: ["get","watch","list"]
apiVersion： rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
name: secret-reader
rules:
- apiGroup: [""]
resources: ["secrets"]
verbs: ["get","watch","list"]
rolebinding与clusterrolebinding
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-secrets
subjects:
- kind: Group
name: manager
apiGroup: rbac.kubernetes.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
通过resourceNames列表，角色可以针对不同种类的请求根据资源名引用资源实例。当指定了resourceNames列表时，不同动作种类的请求的权限，如使用“get”、“delete”、“update”以及“patch”等动词的请求，将被限定到资源列表中所包含的资源实例上。例如，如果需要限定一个角色绑定主体只能“get”或者“update”一个configmap时，可以定义以下角色：
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: configmap-updater
rules:
- apiGroups: [""]
resources: ["configmap"]
resourceNames: ["my-configmap"]
verbs: ["update", "get"]
值得注意的是，如果设置了resourceNames，则请求所使用的动词不能是list、watch、create或者deletecollection。由于资源名称不会出现在create、list、watch和deletecollection等API请求的URL中，所以这些请求动词不会被设置了resourceNames的规则所允许，因为规则中的resourceNames部分不会匹配这些请求。
（2）定义角色示例
允许读取 core API Group 中定义的资源“pods”：
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
允许读写在“extensions” 和“apps” API Group 中定义的“deployments”：
rules:
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
允许读取“pods” 以及读写“jobs”：
- apiGroups: ["batch", "extensions"]
resources: ["jobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
允许读取一个名为“my-config”的ConfigMap实例（需要将其通过RoleBinding绑定从而限制针对某一个命名空间中定义的一个ConfigMap实例的访问）：
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["my-config"]
verbs: ["get"]
允许读取 core API Group 中的“nodes” 资源（由于Node是集群级别资源，所以此ClusterRole定义需要与一个ClusterRoleBinding绑定才能有效）：
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
允许对非资源endpoint“/healthz”及其所有子路径的“GET”和“POST”请求（此ClusterRole定义需要与一个ClusterRoleBinding绑定才能有效）：
rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # 在非资源 URL 中，'*' 代表后缀通配符
verbs: ["get", "post"]