rbac用户权限管理
This time, when I was checking the operation of RBAC, it became a story of user management.
这次，当我检查RBAC的运行时，它成为了用户管理的故事。
Kubernetes provides some authentication modules as standard, but this case I will use X509 Client Certs.
Kubernetes作为标准提供了一些身份验证模块，但是在这种情况下，我将使用X509 Client Certs 。
Create the private key testuser.key and the signature request file testuser.csr.
创建私钥testuser.key和签名请求文件testuser.csr 。
$ openssl genrsa -out testuser.key 2048Generating RSA private key, 2048 bit long modulus.....................................+++.......................................................................+++e is 65537 (0x10001)$ openssl req -new -key testuser.key -out testuser.csrYou are about to be asked to enter information that will be incorporatedinto 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 blankFor 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]:testuserOrganizational Unit Name (eg, section) []:Common Name (eg, your name or your server's hostname) []:testuserEmail Address []:Please enter the following 'extra' attributesto be sent with your certificate requestA challenge password []:An optional company name []: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 oksubject=/C=XX/L=Default City/O=testuser/CN=testuserGetting CA Private Key$ lstestuser.crt testuser.csr testuser.keyAdd the created certificate to the API server.
将创建的证书添加到API服务器。
$ kubectl config set-credentials testuser --client-certificate=testuser.crt --client-key=testuser.key --embed-certs=trueUser "testuser" set.Create a Context for testuser.
为testuser创建一个上下文。
$ kubectl config set-context testuser-context --user=testuser --cluster=kubernetesContext "testuser-context" created.$ kubectl config get-contextsCURRENT NAME CLUSTER AUTHINFO NAMESPACE* kubernetes-admin@kubernetes kubernetes kubernetes-admin testuser-context kubernetes testuserAt the moment, the authority is not set for testuser, so check that the kubectl command causes an error.
目前，尚未为testuser设置权限，因此请检查kubectl命令是否导致错误。
$ kubectl get podError 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@kubernetesSwitched to context "kubernetes-admin@kubernetes".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与群集级别具有不同的设置范围。
Check applied settings:
检查应用的设置：
$ kubectl describe clusterrole readonly-for-allName: readonly-for-allLabels: <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-testName: readonly-for-testLabels: <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-allSubjects: Kind Name Namespace ---- ---- --------- User testuserSwitch the Context and check the operation of RBAC.
切换上下文并检查RBAC的操作。
$ kubectl config get-contextsCURRENT NAME CLUSTER AUTHINFO NAMESPACE* kubernetes-admin@kubernetes kubernetes kubernetes-admin testuser-context kubernetes testuser$ kubectl config use-context testuser-contextSwitched to context "testuser-context".$ kubectl config current-contexttestuser-contextI 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 podNo resources found in default namespace.$ kubectl apply -f nginx.yamlError from server (Forbidden): error when creating "nginx.yaml": pods is forbidden: User "testuser" cannot create resource "pods" in API group "" in the namespace "example"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用户未更改。 从群集外部访问云上的群集时，此设置可能很有用。
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用户权限管理
