Cet article a été inclus dans la rubrique " Apprendre k8s à partir de zéro "
Article précédent : Compréhension approfondie de kubectl Cliquez sauter
Gestion de la configuration avec rbac
Code secret du centre de gestion de la configuration
Qu'est-ce qu'un secret ?
Le Configmap que nous avons appris ci-dessus est généralement utilisé pour stocker des données en clair, telles que des fichiers de configuration. Pour certaines données sensibles, telles que des mots de passe, des clés privées et d'autres données, le type secret est utilisé.
Secret résout le problème de configuration des données sensibles telles que les mots de passe, les jetons et les clés secrètes sans exposer ces données sensibles aux images ou aux spécifications du pod. Le secret peut être utilisé comme volume ou variable d'environnement.
Pour utiliser un secret, le pod doit référencer le secret. Les pods peuvent utiliser les secrets de deux manières : en tant que fichiers dans un volume qui sont montés dans un ou plusieurs conteneurs du pod, ou lorsque le kubelet extrait des images pour le pod. (Par exemple, Harbour Pull, qui stocke le mot de passe de l'utilisateur du port, etc.)
Il existe trois paramètres facultatifs pour le secret :
générique : un type générique, généralement utilisé pour stocker les données de mot de passe.
tls : ce type est uniquement utilisé pour stocker des clés privées et des certificats.
docker-registry : si vous souhaitez enregistrer les informations d'authentification du référentiel docker, vous devez utiliser ce type pour créer.
Type secret :
Compte de service : utilisé pour être référencé par serviceaccount. Lorsque serviceaccout est créé, Kubernetes créera le secret correspondant par défaut. Si le pod utilise serviceaccount, le secret correspondant sera automatiquement monté dans le répertoire /run/secrets/kubernetes.io/serviceaccount du pod.
Opaque : secret au format d'encodage base64, utilisé pour stocker les mots de passe, les clés secrètes, etc. Les données d'origine peuvent être obtenues via le décodage base64-decode, de sorte que la sécurité est faible
kubernetes.io/dockerconfigjson : utilisé pour stocker les informations d'authentification pour le registre Docker privé.
Utiliser secret
1. Introduisez secret via des variables d'environnement pour
créer le mot de passe de l'utilisateur root de mysql en tant que 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
La valeur de password est cryptée, mais le cryptage de secret est un pseudo-cryptage. Il encode simplement les données en base64. Ce qui suit est le décryptage pour trouver le mot de passe crypté dans 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
Monter le secret via le volume
Créer un secret, chiffrer manuellement, basé sur le chiffrement base64
[root@k8smaster secret]# echo -n 'admin' | base64
YWRtaW4=
[root@k8smaster secret]# echo -n 'paopaoshuaige' | base64
cGFvcGFvc2h1YWlnZQ==
解码
[root@k8smaster secret]# echo cGFvcGFvc2h1YWlnZQ== | base64 -d
paopaoshuaige
Créer un fichier yaml
[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
Montez le secret sur le 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/ #
On peut voir d'après ce qui précède que les informations secrètes montées dans le pod ont en fait été déchiffrées.
Autorisation RBAC du mécanisme de sécurité k8s
Gestion de la sécurité k8s : aperçu de l'authentification, de l'autorisation et du contrôle d'admission
k8s a défini des paramètres précis pour l'authentification, l'autorisation et le contrôle d'accès de l'ensemble de notre système ; pour le cluster k8s, l'apiserver est la seule entrée pour le contrôle d'accès de l'ensemble du cluster. Lorsque nous déployons des applications sur le cluster k8s, nous pouvons également passer le récepteur Le port exposé par le NodePort de l'hôte accède au programme à l'intérieur, et l'utilisateur doit passer par le processus d'authentification suivant pour accéder au cluster kubernetes : authentification -> autorisation -> contrôle d'admission (adminationcontroller)
1. L'authentification est l'authentification du client, et le point populaire est l'authentification du nom d'utilisateur et du mot de passe
2. L'autorisation est l'autorisation des ressources. Les ressources dans k8s ne sont rien de plus que des conteneurs. En fin de compte, ce sont en fait les ressources informatiques, réseau et de stockage du conteneur. Lorsqu'une demande est authentifiée, elle doit accéder à un certain ressource (telle que la création d'un pod) , le contrôle d'autorisation déterminera si la ressource (telle qu'un pod sous un espace de noms) est accessible au client conformément aux règles d'autorisation.
3. Mécanisme de contrôle d'admission : le contrôleur d'admission est situé dans le serveur API. Avant que l'objet ne soit persistant, le contrôleur d'admission intercepte la demande adressée au serveur API, qui est généralement utilisé pour l'authentification et l'autorisation. Il contient deux contrôleurs spéciaux :
MutatingAdmissionWebhook et ValidatingAdmissionWebhook. En tant que webhook de contrôle d'admission de mutation et de validation de configuration respectivement.
Mutating Admission Control : Modifier l'objet demandé
Validation du contrôle d'admission : validation de l'objet demandé
Le contrôleur d'admission est configuré dans les paramètres de démarrage du serveur API. Un contrôleur d'admission peut appartenir à l'un ou aux deux ci-dessus. Lorsque la demande arrive au serveur API, le contrôle d'admission de modification est effectué en premier, puis le contrôle d'admission de vérification est effectué.
Lors du déploiement d'un cluster Kubernetes, nous activerons une série de contrôleurs d'admission par défaut. Si ces contrôleurs d'admission ne sont pas définis, on peut dire que votre cluster Kubernetes fonctionne nu. Seul l'administrateur du cluster peut modifier le contrôleur d'admission du cluster.
Par exemple, j'activerais le contrôleur d'admission suivant par défaut.
--admission-control=ServiceAccount,NamespaceLifecycle,NamespaceExists,LimitRanger,ResourceQuota,MutingAdmissionWebhook,ValidatingAdmissionWebhook
L'architecture globale de k8s est également une architecture de microservices. Toutes les requêtes sont effectuées via une passerelle, c'est-à-dire le composant kube-apiserver (qui fournit des services REST au monde extérieur). Il existe deux types de clients dans k8s, l'un est pour utilisateurs ordinaires et l'autre aux utilisateurs ordinaires. Il s'agit d'un pod dans le cluster. Les mécanismes d'authentification de ces deux clients sont légèrement différents, mais quel que soit celui-ci, ils doivent passer par les trois mécanismes d'authentification, d'autorisation, et accéder à son tour.
Certificat
1. L'authentification prend en charge une variété de plug-ins
(1) Authentification par jeton :
Les deux parties ont une clé partagée et un mot de passe est d'abord créé sur le serveur, et le client peut se connecter avec ce mot de passe lors de la connexion. Il s'agit de la méthode d'authentification par clé symétrique. k8s fournit une interface reposante et tous ses services sont fournis via le protocole http, de sorte que les informations d'authentification ne peuvent être transmises que via l'en-tête d'authentification du protocole http, généralement appelé jeton.
(2) authentification ssl :
Pour l'accès k8s, l'authentification ssl permet au client de confirmer l'identité d'authentification du serveur. Lorsque nous communiquons avec le serveur, nous avons besoin que le serveur envoie un certificat. Nous devons confirmer si le certificat est signé par ca. S'il s'agit d'un ca nous reconnaissons Signé, les informations subj qu'il contient sont cohérentes avec les informations de l'hôte cible que nous visitons, il n'y a pas de problème, alors nous pensons que l'identité du serveur a été authentifiée. La chose la plus importante dans k8s est que le serveur doit également authentifier les informations du client, et kubectl doit également avoir un certificat, ce certificat est également un certificat signé par l'autorité de certification reconnue par le serveur.Les deux parties doivent s'authentifier mutuellement pour réaliser une communication cryptée, qui est l'authentification ssl.
2. Compte sur kubernetes
Le client lance une demande auprès du serveur API. Le serveur API doit identifier si l'utilisateur dispose de l'autorisation demandée et s'il peut effectuer l'opération correspondante via le serveur API. Quelles informations sont nécessaires pour identifier les informations utilisateur afin de compléter le contrôle d'accès pertinent pour l'utilisateur?
kubectl expliquer pods.spec peut voir qu'il y a un champ serviceAccountName (nom du compte de service), c'est le compte utilisé lorsque notre pod se connecte à apiserver, il existe donc deux types de comptes dans l'ensemble du cluster kubernetes, ServiceAccount (compte de service), Compte utilisateur (compte utilisateur) compte)
Compte utilisateur : un compte auquel tout le monde peut se connecter en réalité, le client veut initier une demande à l'apiserver, et l'apiserver doit identifier si le client a l'autorisation demandée, alors différents utilisateurs auront des autorisations différentes, selon le Représentation du compte d'utilisateur, appelée nom d'utilisateur
ServiceAccount : il est conçu pour faciliter le processus dans le pod pour appeler l'API Kubernetes ou d'autres services externes. C'est une ressource dans kubernetes
compte sa : le compte utilisé pour se connecter au tableau de bord
compte utilisateur : il s'agit de l'utilisateur qui se connecte à la machine physique k8s
执行kubectl指令的时候会加载文件
[root@k8smaster secret]# cat /root/.kube/config
文件里有一个user用户，做了rbac授权
user: kubernetes-admin
会基于这个用户去访问k8s
écrire à la fin
Ce n'est pas facile à créer, si vous pensez que le contenu vous est utile, merci de me donner un suivi à trois liens pour me soutenir ! S'il y a des erreurs, merci de les signaler dans les commentaires et je les corrigerai en temps voulu !
La série en cours de mise à jour : Apprendre le k8 à partir de zéro
Merci d'avoir regardé, l'article est mélangé à une compréhension personnelle, s'il y a une erreur, veuillez me contacter pour le signaler ~