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:       <none>

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"]