1. Kubernetes的权限控制RBAC

1.1. Kubernetes中的用户

  • User:通常是人来使用,而ServiceAccount是某个服务/资源/程序使用的User独立在K8S之外,也就是说User是可以作用于全局的,在任何命名空间都可被认知,并且需要在全局唯一
  • Service Account:而ServiceAccount作为K8S内部的某种资源,是存在于某个命名空间之中的,在不同命名空间中的同名ServiceAccount被认为是不同的资源。

1.1.1. 用户验证

尽管K8S认知用户靠的只是用户的名字,但是只需要一个名字就能请求K8S的API显然是不合理的,所以依然需要验证此用户的身份

在K8S中,有以下几种验证方式:

  • X509客户端证书:客户端证书验证通过为API Server指定--client-ca-file=xxx选项启用,API Server通过此ca文件来验证API请求携带的客户端证书的有效性,一旦验证成功,API Server就会将客户端证书Subject里的CN属性作为此次请求的用户名
  • 静态token文件:通过指定--token-auth-file=SOMEFILE选项来启用bearer token验证方式,引用的文件是一个包含了 token,用户名,用户ID 的csv文件 请求时,带上Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269头信息即可通过bearer token验证
  • 静态密码文件:通过指定--basic-auth-file=SOMEFILE选项启用密码验证,类似的,引用的文件时一个包含 密码,用户名,用户ID 的csv文件 请求时需要将Authorization头设置为Basic BASE64ENCODED(USER:PASSWORD)

1.1.2. 创建客户端证书的用户凭证

1.为用户创建一个私钥
[root@linux-node1 ~]# openssl genrsa -out jenkins.key 2048

2.为用户创建一个csr(证书签名请求)文件,在subject里带上用户信息(CN为用户名,O为用户组)
[root@linux-node1 ~]# openssl req -new -key jenkins.key -out jenkins.csr -subj "/CN=jenkins/O=vmware"

3.通过已经配置好的CA证书为用户颁发证书
[root@linux-node1 ~]# openssl x509 -req -in jenkins.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out jenkins.crt -days 365

1.2. Kubernetes中的角色

  • Role: 角色,命名空间范围内的一个权限集合。
  • ClusterRole:集群角色,集群范围内的一个权限的集合,

Role和ClusterRole:在Kubernetes中都被定义为集群内部的 API 资源,和我们前面学习过的 Pod、ConfigMap 这些类似,都是我们集群的资源对象,所以同样的可以使用我们前面的kubectl相关的命令来进行操作

  • Subject:主题,对应在集群中尝试操作的对象,集群中定义了3种类型的主题资源:
  • User Account:用户,这是有外部独立服务进行管理的,管理员进行私钥的分配,用户可以使用 KeyStone或者 Goolge 帐号,甚至一个用户名和密码的文件列表也可以。对于用户的管理集群内部没有一个关联的资源对象,所以用户不能通过集群内部的 API 来进行管理
  • Group:组,这是用来关联多个账户的,集群中有一些默认创建的组,比如cluster-admin
  • Service Account:服务帐号,通过Kubernetes API 来管理的一些用户帐号,和 namespace 进行关联的,适用于集群内部运行的应用程序,需要通过 API 来完成权限认证,所以在集群内部进行权限操作,我们都需要使用到 ServiceAccount,这也是我们这节课的重点
  • RoleBinding 和 ClusterRoleBinding:角色绑定和集群角色绑定,简单来说就是把声明的 Subject 和我们的 Role 进行绑定的过程(给某个用户绑定上操作的权限),二者的区别也是作用范围的区别:RoleBinding 只会影响到当前 namespace 下面的资源操作权限,而 ClusterRoleBinding 会影响到所有的 namespace。

1.2.1. 创建角色

[root@linux-node1 ~]# vim jenkins-role.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: jenkins-role
  namespace: jenkins
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["deployments", "replicasets", "pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

1.2.2. 创建角色绑定

[root@linux-node1 ~]# vim jenkins-role-binding.yml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jenkins-rolebinding
  namespace: jenkins
subjects:
- kind: User
  name: jenkins
  apiGroup: ""
roleRef:
  kind: Role
  name: jenkins-role
  apiGroup: ""

1.2.3. 使用自定义用户进行访问

1.将用户tom的验证信息添加进kubectl的配置
[root@linux-node1 ~]# kubectl config set-credentials jenkins --client-certificate=jenkins.crt  --client-key=jenkins.key

2.为用户设置上下文,设置集群和命名空间
[root@linux-node1 ~]# kubectl config set-context jenkins-context --cluster=kubernetes --namespace=jenkins --user=jenkins  

3.在命令中带上--context=jenkins-context即可使用Jenkins用户来操作集群
[root@linux-node1 ~]# kubectl get pods --context=jenkins-context

4.设置当前context
[root@linux-node1 ~]# kubectl config use-context jenkins-context
Copyright © 赵班长@新运维社区 2019 all right reserved,powered by Gitbook该文件修订时间: 2024-06-18 22:25:30

results matching ""

    No results matching ""