重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
本篇内容主要讲解“Kubernetes集群如何添加用户”,感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习“Kubernetes集群如何添加用户”吧!
宿迁ssl适用于网站、小程序/APP、API接口等需要进行数据传输应用场景,ssl证书未来市场广阔!成为创新互联的ssl证书销售渠道,可以享受市场价格4-6折优惠!如果有意向欢迎电话联系或者加微信:13518219792(备注:SSL证书合作)期待与您的合作!
K8S中有两种用户(User)——服务账号(ServiceAccount)和普通意义上的用户(User) ServiceAccount是由K8S管理的,而User通常是在外部管理,K8S不存储用户列表——也就是说,添加/编辑/删除用户都是在外部进行,无需与K8S API交互,虽然K8S并不管理用户,但是在K8S接收API请求时,是可以认知到发出请求的用户的,实际上,所有对K8S的API请求都需要绑定身份信息(User或者ServiceAccount),这意味着,可以为User配置K8S集群中的请求权限。
ServiceAccount是K8S内部资源,而User是独立于K8S之外的。从它们的本质可以看出:
User通常是人来使用,而ServiceAccount是某个服务/资源/程序使用的。
User独立在K8S之外,也就是说User是可以作用于全局的,在任何命名空间都可被认知,并且需要在全局唯一。
ServiceAccount作为K8S内部的某种资源,是存在于某个命名空间之中的,在不同命名空间中的同名ServiceAccount被认为是不同的资源。
K8S不会管理User,所以User的创建/编辑/注销等,需要依赖外部的管理机制。
这里说的添加用户指的是普通意义上的用户,即存在于集群外的用户,为k8s的使用者。
实际上叫做添加用户也不准确,用户早已存在,这里所做的只是使K8S能够认知此用户,并且控制此用户在集群内的权限。
尽管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)
。
这里只介绍客户端验证。
首先需要为此用户创建一个私钥:
openssl genrsa -out tom.key 2048
接着用此私钥创建一个csr(证书签名请求)文件,其中我们需要在subject里带上用户信息(CN为用户名,O为用户组),其中/O参数可以出现多次,即可以有多个用户组:
openssl req -new -key tom.key -out tom.csr -subj "/CN=tom/O=MGM"
找到K8S集群(API Server)的CA证书文件,其位置取决于安装集群的方式,通常会在/etc/kubernetes/pki/路径下,会有两个文件,一个是CA证书(ca.crt),一个是CA私钥(ca.key)。 通过集群的CA证书和之前创建的csr文件,来为用户颁发证书:
openssl x509 -req -in tom.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out tom.crt -days 365
-CA和-CAkey参数需要指定集群CA证书所在位置,-days参数指定此证书的过期时间,这里为365天。
最后将证书(tom.crt)和私钥(tom.key)保存起来,这两个文件将被用来验证API请求。
首先创造一个角色,该角色在acp命名空间下拥有所有权限:
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: acp name: acp-admin rules: - apiGroups: ["*"] resources: ["*"] verbs: ["*"]
将角色和用户tom绑定:
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: acp-admin-binding namespace: acp subjects: - kind: User name: tom apiGroup: "" roleRef: kind: Role name: acp-admin apiGroup: ""
如yaml中所示,RoleBinding资源创建了一个 Role-User 之间的关系,roleRef节点指定此RoleBinding所引用的角色,subjects节点指定了此RoleBinding的受体,可以是User,也可以是前面说过的ServiceAccount,在这里只包含了名为 tom 的用户。 参考:https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding
现在我们想要通过kubectl以tom的身份来操作集群,需要将tom的认证信息添加进kubectl的配置,即~/.kube/config中,通过以下命令将用户tom的验证信息添加进kubectl的配置:
kubectl config set-credentials tom --client-certificate=tom.crt --client-key=tom.key
添加完成后在~/.kube/config可以看到新增了:
users: - name: tom user: client-certificate: /root/k8s/tom.crt client-key: /root/k8s/tom.key
用下面命令添加一个context配置:
kubectl config set-context tom --cluster=kubernetes --namespace=acp --user=tom
添加完成后在~/.kube/config可以看到新增了:
contexts: - context: cluster: kubernetes namespace: acp user: tom name: tom
通过kubectl config get-contexts
命令也可以查到当前kubectl所配置的context信息:
[root@master1 k8s]# kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * kubernetes-admin@kubernetes kubernetes kubernetes-admin tom kubernetes tom acp
使用刚刚新创建的context:
#方式一:切换context kubectl config use-context tom #方式二:使用该context kubectl --context=tom <命令>
将tom.crt/tom.key的内容用BASE64编码:
cat tom.crt | base64 --wrap=0 cat tom.key | base64 --wrap=0
将获取的编码后的文本复制进~/.kube/config文件中:
contexts: - context: cluster: kubernetes namespace: acp user: tom name: tom users: - name: tom user: client-certificate-data: ... client-key-data: ...
到此,相信大家对“Kubernetes集群如何添加用户”有了更深的了解,不妨来实际操作一番吧!这里是创新互联网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!