This article has been included in the column " Learn k8s from scratch "
Previous article: In-depth understanding of kubectl Click jump
Configuration management with rbac
Configuration Management Center Secret
What is a Secret?
The Configmap we learned above is generally used to store plaintext data, such as configuration files. For some sensitive data, such as passwords, private keys and other data, the secret type is used.
Secret solves the configuration problem of sensitive data such as passwords, tokens, and secret keys without exposing these sensitive data to images or Pod Specs. Secret can be used as Volume or environment variable.
To use a secret, the pod needs to reference the secret. Pods can use secrets in two ways: as files in a volume that are mounted into one or more containers in the pod, or when the kubelet pulls images for the pod. (For example, harbor pull, which stores the harbor user password, etc.)
There are three optional parameters for secret:
generic: A generic type, typically used to store password data.
tls: This type is only used to store private keys and certificates.
docker-registry: If you want to save the authentication information of the docker repository, you must use this type to create.
Secret type:
Service Account: used to be referenced by serviceaccount. When serviceaccout is created, Kubernetes will create the corresponding secret by default. If the Pod uses serviceaccount, the corresponding secret will be automatically mounted to the /run/secrets/kubernetes.io/serviceaccount directory of the Pod.
Opaque: Secret in base64 encoding format, used to store passwords, secret keys, etc. The original data can be obtained through base64-decode decoding, so the security is weak
kubernetes.io/dockerconfigjson: used to store authentication information for private docker registry.
Use Secret
1. Introduce secret through environment variables to
create the password of the root user of mysql as secret
[root@k8smaster ~]# kubectl create secret generic mysql-password --from-literal=password=paopaopodshuaige66
secret/mysql-password created
[root@k8smaster secret]# kubectl get secrets
NAME TYPE DATA AGE
mysql-password Opaque 1 60s
[root@k8smaster secret]# kubectl describe secret mysql-password
Name: mysql-password
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 18 bytes
The value of password is encrypted, but the encryption of secret is a pseudo-encryption. It just encodes the data in base64. The following is decryption to find the encrypted password in mysqlpassword.
[root@k8smaster secret]# kubectl get secret -o yaml
- apiVersion: v1
data:
password: eGlhbmNoYW9wb2QqKmx1Y2t5NjY=
[root@k8smaster secret]# echo 'eGlhbmNoYW9wb2QqKmx1Y2t5NjY=' | base64 --decode
paopaopodshuaige66
#创建 pod，引用 secret
[root@k8smaster secret]# vim pod-secret.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-secret
labels:
app: myapp
spec:
containers:
- name: myapp
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
env:
- name: MYSQL_ROOT_PASSWORD #它是 Pod 启动成功后,Pod 中容器的环境变量名.
valueFrom:
secretKeyRef:
name: mysql-password #这是 secret的对象名 把这个secret中的password这个key和对应的value值赋值给上面的变量
key: password #它是 secret 中的 key 名
[root@k8smaster secret]# kubectl apply -f pod-secret.yaml
pod/pod-secret created
[root@k8smaster secret]# kubectl exec -it pod-secret -- /bin/sh
/ # printenv
MYSQL_ROOT_PASSWORD=paopaopodshuaige66
Mount Secret via volume
Create Secret, manually encrypt, based on base64 encryption
[root@k8smaster secret]# echo -n 'admin' | base64
YWRtaW4=
[root@k8smaster secret]# echo -n 'paopaoshuaige' | base64
cGFvcGFvc2h1YWlnZQ==
解码
[root@k8smaster secret]# echo cGFvcGFvc2h1YWlnZQ== | base64 -d
paopaoshuaige
Create yaml file
[root@k8smaster secret]# vim secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: cGFvcGFvc2h1YWlnZQ==
[root@k8smaster secret]# kubectl apply -f secret.yaml
secret/mysecret created
[root@k8smaster secret]# kubectl describe secret mysecret
Name: mysecret
Namespace: default
Labels: <none>
Annotations:
Type: Opaque
Data
====
password: 13 bytes
username: 5 bytes
Mount the Secret to the Volume
[root@xianchaomaster1 ~]# vim pod_secret_volume.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-secret-volume
spec:
containers:
- name: myapp
image: registry.cn-beijing.aliyuncs.com/google_registry/myapp:v1
imagePullPolicy: IfNotPresent
volumeMounts:
- name: secret-volume
mountPath: /etc/secret
readOnly: true
volumes:
- name: secret-volume #把secret做成卷挂载到/etc/secret 只读权限
secret:
secretName: mysecret
[root@k8smaster secret]# kubectl apply -f pod_secret_volume.yaml
pod/pod-secret-volume created
[root@k8smaster secret]# kubectl exec -it pod-secret-volume -- /bin/sh
/ # ls /etc/secret
password username
/ # cat /etc/secret/username
admin
/ # cat /etc/secret/password
paopaoshuaige/ #
It can be seen from the above that the secret information mounted in the pod has actually been decrypted.
RBAC authorization of k8s security mechanism
k8s security management: an overview of authentication, authorization, and admission control
k8s has made precise settings for the authentication, authorization and access control of our entire system; for the k8s cluster, the apiserver is the only entry for the access control of the entire cluster. When we deploy applications on the k8s cluster, we can also pass the sink The port exposed by the NodePort of the host accesses the program inside, and the user needs to go through the following authentication process to access the kubernetes cluster: Authentication -> Authorization -> Admission Control (adminationcontroller)
1. Authenticating is the authentication of the client, and the popular point is the authentication of username and password
2. Authorization is the authorization of resources. The resources in k8s are nothing more than containers. In the end, it is actually the computing, network, and storage resources of the container. When a request is authenticated, it needs to access a certain resource (such as creating a pod) , the authorization check will determine whether the resource (such as a pod under a namespace) is accessible to the customer according to the authorization rules.
3. Admission Control mechanism: The Admission Controller is located in the API Server. Before the object is persisted, the Admission Controller intercepts the request to the API Server, which is generally used for authentication and authorization. It contains two special controllers:
MutatingAdmissionWebhook and ValidatingAdmissionWebhook. As configuration mutation and validation admission control webhook respectively.
Mutating Admission Control: Modify the requested object
Validating Admission Control: Validating the requested object
The admission controller is configured in the API Server startup parameters. An admission controller may belong to one or both of the above. When the request arrives at the API Server, the change admission control is performed first, and then the verification admission control is performed.
When deploying a Kubernetes cluster, we will enable a series of admission controllers by default. If these admission controllers are not set, it can be said that your Kubernetes cluster is running naked. Only the cluster administrator can modify the admission controller of the cluster.
For example, I would enable the following admission controller by default.
--admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota,MutatingAdmissionWebhook,ValidatingAdmissionWebhook
The overall architecture of k8s is also a microservice architecture. All requests are made through a GateWay, that is, the kube-apiserver component (which provides REST services to the outside world). There are two types of clients in k8s, one is for ordinary users, and the other is for ordinary users. It is a Pod in the cluster. The authentication mechanisms of these two clients are slightly different, but no matter which one is, they need to go through the three mechanisms of authentication, authorization, and access in turn.
Certification
1. Authentication supports a variety of plug-ins
(1) Token authentication:
Both parties have a shared key, and a password is created on the server first, and the client can log in with this password when logging in. This is the symmetric key authentication method. k8s provides a restful interface, and all its services are provided through the http protocol, so the authentication information can only be passed through the authentication header of the http protocol, which is usually called a token.
(2) ssl authentication:
For k8s access, ssl authentication allows the client to confirm the authentication identity of the server. When we communicate with the server, we need the server to send a certificate. We need to confirm whether the certificate is signed by ca. If it is a ca we recognize Signed, the subj information inside is consistent with the target host information we visit, there is no problem, then we think that the identity of the server has been authenticated, the most important thing in k8s is that the server also needs to authenticate the client's information, kubectl should also have a Certificate, this certificate is also a certificate signed by the ca recognized by the server. Both parties need to authenticate each other to realize encrypted communication, which is ssl authentication.
2. Account on kubernetes
The client initiates a request to the apiserver. The apiserver needs to identify whether the user has the requested permission and whether the user can perform the corresponding operation through the apiserver. What information is needed to identify the user information to complete the relevant access control to the user?
kubectl explain pods.spec can see that there is a field serviceAccountName (service account name), this is the account used when our pod connects to apiserver, so there are two types of accounts in the entire kubernetes cluster, ServiceAccount (service account), User account (user account) account)
User account: an account that everyone can log in to in reality, the client wants to initiate a request to the apiserver, and the apiserver needs to identify whether the client has the requested permission, then different users will have different permissions, depending on the user Account representation, called username
ServiceAccount: It is designed to facilitate the process in the Pod to call the Kubernetes API or other external services. It is a resource in kubernetes
sa account: the account used to log in to the dashboard
user account: This is the user who logs in to the k8s physical machine
执行kubectl指令的时候会加载文件
[root@k8smaster secret]# cat /root/.kube/config
文件里有一个user用户，做了rbac授权
user: kubernetes-admin
会基于这个用户去访问k8s
write at the end
It is not easy to create, if you think the content is helpful to you, please give me a three-link follow to support me! If there are any mistakes, please point them out in the comments and I will change them in time!
The series currently being updated: Learning k8s from scratch
Thank you for watching, the article is mixed with personal understanding, if there is any error, please contact me to point out~