rbac用户权限管理
介绍(Introduction)
This time, when I was checking the operation of RBAC, it became a story of user management.
这次,当我检查RBAC的运行时,它成为了用户管理的故事。
用户认证设置 (User authentication settings)
Kubernetes provides some authentication modules as standard, but this case I will use X509 Client Certs
.
Kubernetes作为标准提供了一些身份验证模块,但是在这种情况下,我将使用X509 Client Certs
。
创建私钥 (Creating a private key)
Create the private key testuser.key
and the signature request file testuser.csr
.
创建私钥testuser.key
和签名请求文件testuser.csr
。
$ openssl genrsa -out testuser.key 2048
Generating RSA private key, 2048 bit long modulus
.....................................+++
.......................................................................+++
e is 65537 (0x10001)
$ openssl req -new -key testuser.key -out testuser.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:
Organization Name (eg, company) [Default Company Ltd]:testuser
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:testuser
Email Address []:Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
创建签名文件 (Creating a signature file)
Create a signature file testuser.crt
.
创建一个签名文件testuser.crt
。
$ sudo openssl x509 -req -in testuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out testuser.crt -days 10000Signature ok
subject=/C=XX/L=Default City/O=testuser/CN=testuser
Getting CA Private Key$ ls
testuser.crt testuser.csr testuser.key
将证书添加到API服务器 (Adding the certificate to the API server)
Add the created certificate to the API server.
将创建的证书添加到API服务器。
$ kubectl config set-credentials testuser --client-certificate=testuser.crt --client-key=testuser.key --embed-certs=true
User "testuser" set.
上下文设置 (Context settings)
检查集群名称和现有上下文(Check cluster name and existing Context)
$ kubectl config get-clusters
NAME
kubernetes
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* kubernetes-admin@kubernetes kubernetes kubernetes-admin
创建上下文 (Creating Context)
Create a Context for testuser
.
为testuser
创建一个上下文。
$ kubectl config set-context testuser-context --user=testuser --cluster=kubernetes
Context "testuser-context" created.
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* kubernetes-admin@kubernetes kubernetes kubernetes-admin
testuser-context kubernetes testuser
上下文切换 (Context switching)
$ kubectl config use-context testuser-context
Switched to context "testuser-context".
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
kubernetes-admin@kubernetes kubernetes kubernetes-admin
* testuser-context kubernetes testuser
确认书 (Confirmation)
At the moment, the authority is not set for testuser, so check that the kubectl command causes an error.
目前,尚未为testuser设置权限,因此请检查kubectl命令是否导致错误。
$ kubectl get pod
Error from server (Forbidden): pods is forbidden: User "testuser" cannot list resource "pods" in API group "" in the namespace "default"
Once confirmed, revert to the original Context.
确认后,恢复为原始上下文。
$ kubectl config use-context kubernetes-admin@kubernetes
Switched to context "kubernetes-admin@kubernetes".
RBAC设置 (RBAC settings)
Use RBAC to set permissions for the testuser
created so far. There are two types of RBAC,
使用RBAC为设置权限testuser
创建至今。 RBAC有两种类型,
- Role/Role Binding and 角色/角色绑定和
- Cluster Role/Cluster Role Binding.群集角色/群集角色绑定。
Role/RoleBinding has a different setting range from Namespace level, and ClusterRole/ClusterRoleBinding has a different setting range from Cluster level.
Role / RoleBinding与命名空间级别具有不同的设置范围,ClusterRole / ClusterRoleBinding与群集级别具有不同的设置范围。
ClusterRole / ClusterRoleBinding的设置 (Settings of ClusterRole/ClusterRoleBinding)
$ kubectl apply -f RoleCluster.yaml
clusterrole.rbac.authorization.k8s.io/readonly-for-all created
clusterrolebinding.rbac.authorization.k8s.io/readonly-for-test created
Check applied settings:
检查应用的设置:
$ kubectl describe clusterrole readonly-for-all
Name: readonly-for-all
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRole","metadata":{"annotations":{},"name":"readonly-for-all"},"rules":[{"apiGr...
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
--------- ----------------- -------------- -----
*.* [] [] [get list watch]
[*] [] [get]
[*] [] [list]
[*] [] [watch]
$ kubectl describe clusterrolebinding readonly-for-test
Name: readonly-for-test
Labels: <none>
Annotations: kubectl.kubernetes.io/last-applied-configuration:
{"apiVersion":"rbac.authorization.k8s.io/v1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"readonly-for-test"},"roleRef...
Role:
Kind: ClusterRole
Name: readonly-for-all
Subjects:
Kind Name Namespace
---- ---- ---------
User testuser
操作检查 (Operation check)
Switch the Context and check the operation of RBAC.
切换上下文并检查RBAC的操作。
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* kubernetes-admin@kubernetes kubernetes kubernetes-admin
testuser-context kubernetes testuser
$ kubectl config use-context testuser-context
Switched to context "testuser-context".
$ kubectl config current-context
testuser-context
I don’t have a pod, but the kubectl get pod command, which was in error before configuring RBAC, is returning successfully.Also, creating a pod has failed because you don’t have permission.
我没有Pod,但是在配置RBAC之前出错的kubectl get pod命令成功返回。此外,由于没有权限,创建Pod失败。
$ kubectl get pod
No resources found in default namespace.
$ kubectl apply -f nginx.yaml
Error from server (Forbidden): error when creating "nginx.yaml": pods is forbidden: User "testuser" cannot create resource "pods" in API group "" in the namespace "example"
结论 (Conclusion)
The flow of user authentication is as follows. Since the verification environment this time is an on-premise environment, the API server and client will be on the same node. So, the only user switching is Context switching, and the OS user has not changed. Perhaps this setting will be useful when accessing a cluster on the cloud from outside the cluster.
用户认证的流程如下。 由于这次的验证环境是内部部署环境,因此API服务器和客户端将位于同一节点上。 因此,唯一的用户切换是上下文切换,并且OS用户未更改。 从群集外部访问云上的群集时,此设置可能很有用。
![Image for post](https://i-blog.csdnimg.cn/blog_migrate/d9104e7ae3f9d3ea8d1d79f56aeb6d6f.png)
RBAC itself should be linked with resources, and Role and Cluster Role are also prepared by default, so I think it is easy to understand.
RBAC本身应该与资源链接在一起,并且默认情况下还准备了Role和Cluster Role,因此我认为这很容易理解。
翻译自: https://medium.com/@iced_burn/kubernetes-user-management-rbac-a436cc871cb3
rbac用户权限管理