rbac of k8s permission control

Permission control

rbac based permission control is introduced here, which mainly involves four concepts: role (role,clusterrole), role binding (role binding, clusterrole binding), authorization object (serviceaccount, user) and permission (apiGroups,resources,verbs)

Difference between serviceaccount and user

sa is usually used for application authorization in pod. For example, if the program in pod wants to access the cluster and do some operations, it can use sa. The default pod has a default sa

User is usually used by people, and it marks individuals. For example, multiple users in kubectl configuration file are defined by user.

However, there are no strict restrictions on the use of both

Permission assignment based on serviceaccount

Role authorization for namespace

###Roles are bound with some permissions. Roles are namespace based. Cluster roles are global. That is, roles bound to users or sa work in a fixed namespace.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: {{ .Release.Name }}
rules:
  - apiGroups:
    - "*"
    resources:
    - "*"
    verbs:
    - list
    - get
    - create


###RoleBinding is a namespace resource object that binds serviceaccount and role together
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: {{ .Release.Name }}-binding
RoleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: {{ .Release.Name }}
subjects:
- kind: ServiceAccount
  name: {{ .Release.Name }}


###serviceaccount is based on namespace. With its creation, a token with the same name will be automatically generated in the namespace
apiVersion: v1
kind: ServiceAccount
metadata:
  name: {{ .Release.Name }}

Cluster permission control

###The difference between a cluster role and an ordinary role is that the corresponding permissions of the cluster role are the permissions of the whole cluster, all namespace resources and cluster objects that do not belong to the namespace
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: langkai-u-all
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - list
  - get
  - watch


###Role binding
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: langkai-u-all-cluster-binding
roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: langkai-u-all
subjects:
- kind: ServiceAccount
  name: langkai-u-all


ServiceAccount The same as above, through serviceaccount Corresponding token You can log in kuboard Carry out corresponding operation

Use of user based permission assignment in kubectl configuration file

kubectl accesses apiserver based on the user's home directory kube/config is configured to complete the verification.

Application scenario:

There are two clusters, prd and dev. access the two clusters through the same kubectl, access the frontend namespace of prd cluster through user user1, and access the backend namespace of dev through user user2. At this time, you need to configure different contexts in config to realize the two accesses.

 

Introduce several concepts of cluster user context

1. A cluster is a k8s cluster, in which cluster certificates, addresses and other information are configured;

2. The user is the authorization object. Configure the authentication information, and then authorize the user through rbac to access the cluster;

3. Context is to associate cluster + user + namespace. For example, user tom + cluster k8s New + namespace dev means that all operations performed by kubectl command in this context are performed in the space dev of cluster k8s new as tom

config configuration file

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tDQpNSUlDeURDQ0FiQ2dBd0lCQWdJQkFEQU5CZ2txaGtpRzl3MEJBUXNGQURBVk1STXdFUVlEVlFRREV3cHJkV0psDQpjbTVsZEdWek1CNFhEVEl3TURreE5UQTVNekl3TUZvWERUTXdNRGt4TXpBNU16SXdNRm93RlRFVE1CRUdBMVVFDQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTHE1DQpmVVpWT3RTRzhocTV2Tk8xUzJmTkQrVnd5TjFYb25lT1JrbXV5ZHRPMHJSQ0VwSWdjZFg1d3pvek40L0s3Rld1DQp6MzZmWm9yV3JTWjFyMzNWcUNzdzZlUFVQcmJQaU5ZSStQdEszU29icHh4ZVQ5KzlUSVpxVmc2UTJhcEExckM5DQpObTBuMCswdmh0SUxjeGs3amRXM3QrSkhiWWhlNE4zZ2tCUUVoaS9OVDNyZDJUNzQ3SFk5L1ZmUFdHZStNTEZwDQo1V056T2ZyL0ZqWUhVMmR5dnRZMnl6VlVaeFBPRitaTjlENGpHWmpDbzR5MFdhTVBOeUxGV056dnQ4NkM1dmYrDQppUUZTN2E4bVo1emwybWFabldtZ204bjVLNUd0QWdNM3VVZXh1QlZpOXZ5OCt3K3kralcyYnR6QmkwRUgxYUQ2DQppbW1UUVZsaHdscEhpWU1STEIwQ0F3RUFBYU1qTUNFd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCDQovd1FGTUFNQkFmOHdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBRjRhTElSRm10R210NDd6UVFZKy9yb2FEK3pIDQoxUnZnMStDYjk4NnZkbENtc08ybVNadldyb2tYUTFtL2pyMzUxeW1xUzNwU3FId05kOUdFaWg5cWJpYmpTQXhCDQo4RU1vUmxhclBRUDBRemlNcytIR1N1RHRYYW95RzZvN3RnQVErV1R1NUdBazBPWnRlcVdhdzVKK2FQZGIydEluDQpqSWVyUW1BMmhnYlRoVFdDbjIwL2lrUUVWSm44OFQvYU1YUG01TGdPbXQ2RGdpbHZEKzdySFBONk5WY1NvcmFXDQoydE9qd3VJa0tMSFhUcFZwb213UDU3UGl1VWNxSTV0NjVuaTQ1WEhoVDBnS0F2ZUZCa2wxZzJ0M00veTdvTU9yDQp6R2Q4MW1ORTMrQzV6WWdHL2ZsTWREeVVLTzcvNXhDbVYvNVRkWkIxWTVEWm1DYkNaUDJhazBnMnVaZz0NCi0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0=
    server: https://192.168.1.200:8443
  name: k8s-new
- cluster:
    server: https://192.168.1.210:8443
  name: k8s-old



contexts:
- context:
    cluster: k8s-new
    user: langkai
  name: k8s-new-all
- context:
    cluster: k8s-new
    namespace: langkai
    user: langkai
  name: k8s-new-langkai
- context:
    cluster: k8s-old
    namespace: default
    user: kzf
  name: k8s-old-default
current-context: k8s-new-langkai


kind: Config
preferences: {}
users:
- name: kzf
  user:
    password: 1qaz2wsx
    username: kouzhenfang
- name: langkai
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNvekNDQVlzQ0NRQ0Jwa2dGSUhoTGx6QU5CZ2txaGtpRzl3MEJBUXNGQURBVk1STXdFUVlEVlFRREV3cHIKZFdKbGNtNWxkR1Z6TUI0WERUSXdNVEF4TWpBek5EUXlNbG9YRFRJeE1UQXhNakF6TkRReU1sb3dFakVRTUE0RwpBMVVFQXd3SGJHRnVaMnRoYVRDQ0FTSXdEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTTROClN6ZUZkVjNIT2FWR1FVbmpSUFFrS2h4Z2ZkT2xJdVFlb243UGtEeHhwb0d5SkE4UkNqbUpXcVhDT2lhbWtma2QKMWhPT3k0Z2M5K2F0M2JDZkRjMjI2VENyUUg5RVUyL1R3ejhvd3FRdWoyTG1EdnB1ZVBGWUNsRlNLeU1GMTYzMApaL3FpamU1YnlWK1p3TklKaC92bzVNbStPZlV3QjRzWmJIeFJxb1pOb3I3dytjbEk1M3VYMm5uNEVobEFxL3hLCmwxcXhmeFRXNEJ4RVZ3cWx2Z2Q2aFBlVS90SUJDbjJ5YVhCVW52WkF0aEhjRjV3aDdpcW9OYUF1Yi9zR1c4elEKdURMYUxNOHFnd3pVZDd6ZVhuNTc1K1hLcGU3UEVuKzFOVjZSTkg1bUNtdkI0VDUrcXl1VFBCWW9lTXV6eS84UQpya2pQREZNZ1A5TmUyK25sK1hzQ0F3RUFBVEFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBYjdGL1BUZnlTK3ovClp6eGZ2Y2g2YmxGVGZXaTFiZGRXemdWd1pOVWlrMUxiUEFmMGxsM2hDMjJoRUlvNm5CUXRnMG1XNzVNY3VlZWwKMXZ1VldMaVN2ZGd6aWRZcmtseFgwY2d3d3p6MjNwSWhJM0dVUjU3QU55N212ZTBIMjM2eWNsZi9SNkFTdE9BcAo5eUlkYWkwWjk2ejRzK1FDaldNOWw2Y2JDNnhDbUlEMEhGTHRMNHhmTXlnSHd2YmRtQTNxbGl2alRwVUEzMEZTCjl2M2tiRXpvRDAvbE1HQ1hZZlJpb1FlV0w0TjJVOExMeldFT2NmSTg2Tm4xVFdtRGZXcmVhSExFSHU2NTZlWkQKUy9ucjMrRVVHL09YUndaVnc0V0QrL3VoZlFIbkNvdjZWUEN3bXR3TXNOM1NlVE5MWk1vU3BKVWlyN1VtTlJNVQpLYjZla3VQNU1RPT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBemcxTE40VjFYY2M1cFVaQlNlTkU5Q1FxSEdCOTA2VWk1QjZpZnMrUVBIR21nYklrCkR4RUtPWWxhcGNJNkpxYVIrUjNXRTQ3TGlCejM1cTNkc0o4TnpiYnBNS3RBZjBSVGI5UERQeWpDcEM2UFl1WU8KK201NDhWZ0tVVklySXdYWHJmUm4rcUtON2x2Slg1bkEwZ21IKytqa3liNDU5VEFIaXhsc2ZGR3FoazJpdnZENQp5VWpuZTVmYWVmZ1NHVUNyL0VxWFdyRi9GTmJnSEVSWENxVytCM3FFOTVUKzBnRUtmYkpwY0ZTZTlrQzJFZHdYCm5DSHVLcWcxb0M1dit3WmJ6TkM0TXRvc3p5cURETlIzdk41ZWZudm41Y3FsN3M4U2Y3VTFYcEUwZm1ZS2E4SGgKUG42cks1TThGaWg0eTdQTC94Q3VTTThNVXlBLzAxN2I2ZVg1ZXdJREFRQUJBb0lCQVFES3NhOGRWZTdIcXBTZApiY2dKL0VTM2VkL20vRkNxNDFhNFd4NTBhcEN6dFFVYnJuYmtUMW5ra2FhWFNzSlRoU1l4amxVcDloMW5yejk2CkwrelZzeEVzSFZPMWFiRlB3SkhuZnNRaG5HSWtpaHpKS0JEeDc3eVBoWkRZd0dEbzJmVjZET1JBWEtvTUlVU3UKQTV6M3dTS0EvM0FZdVVWZ1diZ0I4S2VVZisya29IS0ZjQUM1N1VJUklDcy9qSDV3SGJBSFdFR0NNRWRQdUdrUgpBZXBSQkxXdERURjduSFBLSk02VEJrMnc2c2lwMFpyWkpKbFZycDd1UzFYcHNkbmtLOEVRY3BLK3ZoT1NUUlVaCjB0d2lwNEVZand1Rks1bTIySVlHQlBVaEFWY2VOMExsekFKUk5vUFNsWkREWGYyMVZtS3RaM3VWTEs5T3BkNGcKNXYrazRuUlpBb0dCQVAwd3NGYitseUV4a1ZWbnF2ZVBzZ3o5S3ZvUmVLQ09oOHEvNUZKR2VhYWN1ZFpJeGVOUgpPN3FHa1VYNFB1K21kZVhKRXFoOVBhRzQ0Uy9HcGUvTjFFR3dIUVJiWU1kSXNoT2RqUUJ6TWF6TWo3N0ZCcVRqCm8zUzVTNVlrOFgrN2d0NElmeTNtWDVQNDdnZkN4aDZuc1RkbTY1dVpDMlluQ1lpZ3k2bi9aaEgvQW9HQkFOQlcKcjRMQU9DRkk2S0VkZCtmekdXUStOVU9yUWEvR2RiMnlsRlY5c2xNMExseElrUWRjT0YvU1l4N0RQM3ozV2UwYgpLdGluZUpuejZpb2NwSElRV2owcW13UEFONlFsRnVhQ3JWc0FReEs0UVdwamprTXFVVEtLN2JhaE5mditPUnB0ClY5RStoWTgvNnlOMktZMVRBMlQ0M2d5dERoYjAxa0MrRm8zZTRXQ0ZBb0dBUjQ5cVY3d3ZSTjk0bnpYa3VZR3cKcGtFcjAyLzZzdzUxek5VOW1BOTVOS0VaV1RwS1MveGFzRloyV3R0V0ZtL3E1SjVYR3E0RExHRlByQ3d1SEVBRgpuT2RFM0VWamJnL2EzUFpyc3RQY0YyWGR2dUo3QlVHZG9sRDR6eC96N2RFMnBNQ3NDWElTVTRWSTZZS2djbXVkCkIvYWI0dWQzdEZDV1BqcU1OYWtNMVVzQ2dZQitmWU1HRVlxQ3V1OXlrcCt3VmlwK2NENktuVG0rYlBJamdIOEwKQU12Nk5GNUpiVTJRZUc5SnprU2I4dE5qSGhLZElMZDgzd0VjQjdtT1krRjcxMjNTWVVISW56V3BGVk80RkhNSQpJenFWN1FUYWdTTm9xQkt3YXlVMGt1Qmg1TkhxdDZSdnlGUHl5MDRLTTcyNnJrSUxWZ1lMRUM3VHhVY24rOEZaCjFZNWt1UUtCZ0ZUMXFjakF4ME9NaGF3dVI4ODJycmNnMTFWR2hBQU5uZGtMa3ZIUVN0bEc0Zyt3Tkg3ZHB6MTkKbzJhdjUrcHdONlhWQVBBR2k2SzM0MFVlNkt6NGVTUzNWR3Flb0RNSXJrcVdtby9qV1lxM1hoWXowU29VRkFORgpyNkZSZy9YREo5SXhkUWZyMXpBaEM1UytmbjJ1Q3F4V1NPV0FlMEFJRGZ4Ym9uTVlIeUxTCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
Key points:

1. The user's authentication information can only be a key pair, and the user password form does not take effect

2. The cluster must also configure its certificate, otherwise an error will be reported when accessing: there are no relevant resources

User certificate generation:

###Create a private key
umask 077; openssl genrsa -out langkai.key 2048
###Create certificate request
openssl req -new -key langkai.key -out langkai.csr -subj "/CN=langkai"
###Create certificate based on certificate request and ca public-private key of cluster
openssl x509 -req -in langkai.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out langkai.crt -days 365
Configure public and private key information to config in client-certificate-data and client-key-data place

kubectl config set-credentials langkai  --client-certificate=./langkai.crt --client-key=./langkai.key --embed-certs=true

perhaps
cat langkai.crt | base64   
Configure the encoded information in config in client-key-data and client-certificate-data place

Switch context

kubectl config --kubeconfig=config-demo use-context dev-frontend  
#--kubeconfig The configuration file path is specified. If it is not specified, it is the default~/.kube/config  
#The actual operation is to change the config file, or you can manually specify the context in the configuration file
current-context: k8s-new-langkai

to grant authorization

Only authorized to users kubectl Can be used, otherwise the cluster cannot be operated. The authorization is divided into two parts: cluster+Namespace resource

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: langkai-u-all
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - list
  - get
  - watch


---
# Source: fengmi-frontend/templates/clusterrolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: langkai-u-all-cluster-binding
roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: ClusterRole
   name: langkai-u-all
subjects:
- kind: User
  name: langkai-u-all


---
# Source: fengmi-frontend/templates/role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: langkai-u-all
rules:
- apiGroups:
  - "*"
  resources:
  - "*"
  verbs:
  - "*"


---
# Source: fengmi-frontend/templates/rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: langkai-u-all-binding
roleRef:
   apiGroup: rbac.authorization.k8s.io
   kind: Role
   name: langkai-u-all
subjects:
- kind: User
  name: langkai-u-all

About users:

The user is not a resource object in a cluster, that is, the user does not need to create an additional one, but the serviceaccount needs to be created. The user only needs to define it in config, and the sa must be created through yaml or command.

Posted by blacksnday on Wed, 11 May 2022 21:08:43 +0300