RBAC de gestion des autorisations Kubernetes (k8s)

RBAC

Dans l'article précédent, nous avons découvert Kubernetesdeux objets de ressource importants utilisés pour les informations de configuration : ConfigMapet Secret, en fait, nous avons essentiellement couvert certains objets de ressource importants ici Kubernetes, et le déploiement d'une application ne pose aucun problème. Avant de vous montrer un exemple complet, nous devons vous expliquer un concept important : RBAC- Contrôle d'accès basé sur les rôles.

RBACUtilisez rbac.authorization.k8s.iole groupe d'API pour mettre en œuvre des décisions d'autorisation, permettant aux administrateurs de configurer dynamiquement des stratégies via l'API Kubernetes. Pour l'activer, vous devez ajouter RBACdes paramètres dans l'apiserver --authorization-mode=RBAC. Si vous utilisez kubeadmun cluster installé, il est activé par défaut dans les versions supérieures à 1.6 RBAC. Vous pouvez le visualiser sur le nœud Master. PodFichier de définition statique d'apiserver :

$ cat /etc/kubernetes/manifests/kube-apiserver.yaml 
...
    - --authorization-mode=Node,RBAC
...

Si le cluster est construit en mode binaire, n'oubliez pas de redémarrer le service apiserver après avoir ajouté ce paramètre.

Objets API RBAC

KubernetesUne fonctionnalité très basique est que tous ses objets de ressource sont des objets d'API modélisés , permettant les opérations CRUD (Créer, Lire, Mettre à jour, Supprimer) (c'est-à-dire que nous disons souvent ajouter, supprimer, modifier, vérifier les opérations), Par exemple, la ressource suivante :

• Gousses
• ConfigMaps
• Déploiements
• Nœuds
• secrets
• Espaces de noms

Les opérations possibles des objets de ressource ci-dessus sont :

• créer
• obtenir
• supprimer
• liste
• mise à jour
• modifier
• montre
• exec

À un niveau supérieur, ces ressources sont associées au groupe d'API. Par exemple, elles Podsappartiennent au groupe d'API principal et Deployementsappartiennent au groupe d'API d'applications. Outre les ressources et les opérations Kubernetesci-dessus RBAC, nous avons également besoin d'autres objets :

• Règle : les règles, les règles sont un ensemble d'opérations qui appartiennent à différentes ressources du groupe d'API

• Rôle et ClusterRole : rôle et rôle de cluster, les deux objets contiennent l'élément Rules ci-dessus, la différence entre les deux est que dans Role, les règles définies ne s'appliquent qu'à un seul espace de noms, qui est associé à l'espace de noms, tandis que ClusterRole est à l'échelle du cluster , les règles définies ne sont donc pas liées par des espaces de noms. De plus, Role et ClusterRole Kubernetessont définis comme des ressources d'API à l'intérieur du cluster, qui sont similaires au Pod et au ConfigMap que nous avons appris auparavant. Ce sont tous des objets de ressource de notre cluster, nous pouvons donc également utiliser les commandes associées que nous avons mentionnées précédemment pour kubectlfonctionner

• Objet : Objet, correspondant à l'objet qui tente d'opérer dans le cluster. Trois types de ressources d'objet sont définis dans le cluster :

  • Compte utilisateur : Utilisateur, qui est géré par un service externe indépendant.L'administrateur distribue la clé privée.L'utilisateur peut utiliser un compte KeyStone ou Google, ou encore un fichier liste de noms d'utilisateurs et de mots de passe. Il n'y a pas d'objet ressource associé dans le cluster de gestion de l'utilisateur, donc l'utilisateur ne peut pas le gérer via l'API à l'intérieur du cluster
  • Groupe : groupe utilisé pour associer plusieurs comptes. Certains groupes sont créés par défaut dans le cluster, tels que cluster-admin
  • Compte de service : compte de service, Kubernetescertains comptes d'utilisateurs gérés via l'API, associés à l'espace de noms, adaptés aux applications s'exécutant à l'intérieur du cluster, doivent effectuer une authentification d'autorisation via l'API, nous devons donc l'utiliser pour effectuer des opérations d'autorisation à l'intérieur du cluster To ServiceAccount, qui est également au centre de notre leçon

• RoleBinding et ClusterRoleBinding : la liaison de rôle et la liaison de rôle de cluster, en termes simples, est le processus de liaison du sujet déclaré avec notre rôle (pour lier un utilisateur ayant l'autorité d'opérer), la différence entre les deux est également la portée de l'action. différence : RoleBinding n'affectera que les autorisations d'opération de ressource sous l'espace de noms actuel, tandis que ClusterRoleBinding affectera tous les espaces de noms.

Ensuite, montrons les méthodes de configuration suivantes à travers quelques exemples RBAC.

Créer un utilisateur qui ne peut accéder qu'à un certain espace de noms

Créons un compte utilisateur qui ne peut accéder qu'à l'espace de noms kube-system :

• nom d'utilisateur : haimaxy
• groupe: youdianzhishi

Étape 1 : Créer des informations d'identification utilisateur

Comme nous l'évoquions précédemment, Kubernetesil n'y a pas d'objet API pour User Account, mais il est assez simple de créer un compte utilisateur en utilisant une clé privée qui vous est attribuée par l'administrateur.Pour cela, nous pouvons nous référer à la méthode dans le document officiel , ici on utilise OpenSSLdes certificats pour créer un Utilisateur, bien sûr on peut aussi utiliser cfssldes outils plus simples pour créer :

• Créez une clé privée pour l'utilisateur haimaxy et nommez-la : haimaxy.key :

$ openssl genrsa -out haimaxy.key 2048

• Utilisez la clé privée que nous venons de créer pour créer un fichier de demande de signature de certificat : haimaxy.csr, veillez à bien préciser le -subjnom d'utilisateur et le groupe dans les paramètres (CN signifie nom d'utilisateur, O signifie groupe) :

$ openssl req -new -key haimaxy.key -out haimaxy.csr -subj "/CN=haimaxy/O=youdianzhis"

• Ensuite, recherchez notre Kubernetescluster CA. Nous utilisons le kubeadmcluster installé. CALes certificats pertinents se trouvent /etc/kubernetes/pki/sous le répertoire. Si vous le construisez en mode binaire, vous devez avoir spécifié CAle répertoire lors de la première construction du cluster. Nous utiliserons ce répertoire ci-dessous ca.crtet ca.keydeux fichiers pour approuver la demande de certificat ci-dessus

• Générez le fichier de certificat final, ici nous fixons la durée de validité du certificat à 500 jours :

$ openssl x509 -req -in haimaxy.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out haimaxy.crt -days 500

Vérifiez maintenant si un fichier de certificat est généré dans notre dossier actuel :

$ ls
haimaxy.csr haimaxy.key haimaxy.crt

• Nous pouvons maintenant créer de nouveaux identifiants et contextes dans le cluster à l'aide des fichiers de certificat et de clé privée que nous venons de créer :

$ kubectl config set-credentials haimaxy --client-certificate=haimaxy.crt  --client-key=haimaxy.key

Nous pouvons voir qu'un utilisateur haimaxyest créé, puis définir un nouveau contexte pour cet utilisateur :

$ kubectl config set-context haimaxy-context --cluster=kubernetes --namespace=kube-system --user=haimaxy

À ce stade, notre utilisateur haimaxya été créé avec succès. Maintenant, lorsque nous utilisons le fichier de configuration actuel pour exécuter kubectldes commandes, une erreur doit se produire, car nous n'avons défini aucune autorisation d'opération pour cet utilisateur :

$ kubectl get pods --context=haimaxy-context
Error from server (Forbidden): pods is forbidden: User "haimaxy" cannot list pods in the namespace "default"

Étape 2 : Créer le personnage

Une fois l'utilisateur créé, il est nécessaire d'ajouter des autorisations d'opération à l'utilisateur. Définissons un YAMLfichier et créons un rôle qui permet à l'utilisateur d'exploiter le déploiement, le pod et les ReplicaSets, comme défini ci-dessous : (haimaxy-role.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: haimaxy-role
  namespace: kube-system
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["deployments", "replicasets", "pods"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] # 也可以使用['*']

Parmi eux Pod, il appartient au groupe d'API principal, YAMLet vous pouvez y utiliser des caractères vides, et Deploymentil appartient au groupe d'API d'applications, ReplicaSetsqui appartient à extensionsce groupe d'API (comment le savoir ? Cliquez ici pour consulter le document ), donc les apiGroups sous règles synthétisent ces ressources Groupe d'API : ["", "extensions", "apps"], qui sont les opérations que nous avons mentionnées verbsci-dessus qui peuvent être effectuées sur ces objets de ressource. Nous avons besoin de toutes les méthodes d'opération ici, afin que nous puissions utilisez également ['*' ] à la place.

Créez ensuite ceci Role:

$ kubectl create -f haimaxy-role.yaml

Notez que nous n'utilisons pas haimaxy-contextle contexte ci-dessus ici, car il n'y a pas d'autorisation

Étape 3 : Créer une liaison d'autorisation de rôle

Le rôle est créé, mais évidemment notre rôle n'a rien à voir avec notre utilisateur haimaxy, n'est-ce pas ? Ici, je dois créer un RoleBindingobjet et lier le rôle haimaxy-role ci-dessus à l'utilisateur haimaxy sous l'espace de noms kube-system : (haimaxy-rolebinding.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: haimaxy-rolebinding
  namespace: kube-system
subjects:
- kind: User
  name: haimaxy
  apiGroup: ""
roleRef:
  kind: Role
  name: haimaxy-role
  apiGroup: ""

Dans le YAMLfichier ci-dessus, nous avons vu subjectsdes mots clés, voici l'objet que nous avons mentionné ci-dessus pour essayer de faire fonctionner le cluster, ici correspond au compte utilisateur ci-dessus haimaxy, à utiliser pour kubectlcréer l'objet ressource ci-dessus :

$ kubectl create -f haimaxy-rolebinding.yaml

Étape 4. Testez

Nous devrions maintenant pouvoir haimaxy-contextfaire fonctionner le cluster avec le contexte ci-dessus :

$ kubectl get pods --context=haimaxy-context
....

Nous pouvons voir kubectlque l'espace de noms que nous utilisons n'a pas été spécifié. C'est parce que nous avons attribué des autorisations à l'utilisateur. Et si nous en ajoutions un plus tard-n default ?

$ kubectl --context=haimaxy-context get pods --namespace=default
Error from server (Forbidden): pods is forbidden: User "haimaxy" cannot list pods in the namespace "default"

Est-ce conforme à nos attentes ? Parce que l'utilisateur n'a pas l'autorisation d'opération de l'espace de noms par défaut

Créer un ServiceAccount qui ne peut accéder qu'à un certain espace de noms

Ci-dessus, nous avons créé un utilisateur ordinaire qui ne peut accéder qu'à un certain espace de noms. Comme nous l'avons mentionné précédemment, il existe également une ressource de sujet du même type sous les sujets : ServiceAccount. Créons maintenant un utilisateur dans le cluster qui ne peut utiliser que kube-system pour les pods et les déploiements sous cet espace de noms, créez d'abord un objet ServiceAccount :

$ kubectl create sa haimaxy-sa -n kube-system

Bien sûr, on peut aussi le définir YAMLcomme un fichier à créer.

Créez ensuite un nouvel objet Rôle : (haimaxy-sa-role.yaml)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: haimaxy-sa-role
  namespace: kube-system
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Vous pouvez voir que le rôle que nous avons défini ici n'est pas autorisé à créer, supprimer et mettre à jour des pods. Nous pouvons nous concentrer sur les tests plus tard et créer l'objet Rôle :

$ kubectl create -f haimaxy-sa-role.yaml

Créez ensuite un objet RoleBinding pour lier le haimaxy-sa ci-dessus au rôle haimaxy-sa-role : (haimaxy-sa-rolebinding.yaml)

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: haimaxy-sa-rolebinding
  namespace: kube-system
subjects:
- kind: ServiceAccount
  name: haimaxy-sa
  namespace: kube-system
roleRef:
  kind: Role
  name: haimaxy-sa-role
  apiGroup: rbac.authorization.k8s.io

Ajoutez cet objet ressource :

$ kubectl create -f haimaxy-sa-rolebinding.yaml

Alors, comment vérifions-nous ce ServiceAccount ? Avons-nous mentionné dans le cours précédent qu'un ServiceAccount générera un objet secret et le mappera, ce secret contient un jeton, nous pouvons utiliser ce jeton pour nous connecter au tableau de bord, puis nous pouvons vérifier nos fonctions dans le tableau de bord. Est-ce comme attendu:

$ kubectl get secret -n kube-system |grep haimay-sa
haimay-sa-token-nxgqx                  kubernetes.io/service-account-token   3         47m
$ kubectl get secret haimay-sa-token-nxgqx -o jsonpath={
    
    .data.token} -n kube-system |base64 -d
# 会生成一串很长的base64后的字符串

Utilisez le jeton ici pour vous connecter à la page Tableau de bord :

Nous pouvons voir les informations d'invite ci-dessus, car nous passons par défaut à l'espace de noms par défaut après la connexion, nous pouvons passer à l'espace de noms kube-system ci-dessous :

Nous pouvons voir que la liste des pods est accessible, mais il y aura également d'autres invites supplémentaires : les événements sont interdits : l'utilisateur « system:serviceaccount:kube-system:haimaxy-sa » ne peut pas répertorier les événements dans l'espace de noms « kube-system » , Cela est dû au fait que l'utilisateur de connexion actuel est uniquement autorisé à accéder à l'espace et au déploiement. De même, est-il acceptable de visiter le déploiement ?

De même, vous pouvez restreindre les autorisations d'accès des utilisateurs en fonction de vos propres besoins, vous pouvez définir des autorisations plus précises via le rôle ou vous pouvez utiliser certaines autorisations intégrées dans le système...

Créer un ServiceAccount pouvant accéder à tous les espaces de noms

Le ServiceAccount que nous venons de créer haimaxy-saest lié à un rôle de rôle. Si nous créons un nouveau ServiceAccount maintenant, ses autorisations d'opération doivent s'appliquer à tous les espaces de noms. À ce stade, nous devons utiliser deux objets de ressource, ClusterRole et ClusterRoleBinding. De même, créez d'abord un objet ServiceAcount : (haimaxy-sa2.yaml)

apiVersion: v1
kind: ServiceAccount
metadata:
  name: haimaxy-sa2
  namespace: kube-system

créer:

$ kubectl create -f haimaxy-sa2.yaml

Créez ensuite un objet ClusterRoleBinding (haimaxy-clusterolebinding.yaml) :

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: haimaxy-sa2-clusterrolebinding
subjects:
- kind: ServiceAccount
  name: haimaxy-sa2
  namespace: kube-system
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

D'après ce qui précède, nous pouvons voir que nous n'avons pas déclaré d'espace de noms pour cet objet de ressource, car il s'agit d'un objet de ressource ClusterRoleBinding qui agit sur l'ensemble du cluster, et nous n'avons pas créé d'objet ClusterRole séparé, mais utilisé l'objet cluster-admin, Il s'agit Kubernetesde l'objet ClusterRole intégré du cluster. Nous pouvons utiliser kubectl get clusterroleet kubectl get clusterrolebindingafficher certains rôles de cluster intégrés et liaisons de rôles de cluster dans le système. Ici, nous utilisons le rôle de cluster cluster-admin avec la plus haute autorité, nous avons donc généralement besoin utiliser ce rôle de cluster avec prudence. .

Créez l'objet de ressource de liaison de rôle de cluster ci-dessus et utilisez le jeton correspondant au ServiceAccount pour vous connecter au tableau de bord pour vérification après la création :

$ kubectl create -f haimaxy-clusterolebinding.yaml
$ kubectl get secret -n kube-system |grep haimay-sa2
haimay-sa2-token-nxgqx                  kubernetes.io/service-account-token   3         47m
$ kubectl get secret haimay-sa2-token-nxgqx -o jsonpath={
    
    .data.token} -n kube-system |base64 -d
# 会生成一串很长的base64后的字符串

Lorsque nous sommes entrés en contact avec RBACl'authentification pour la première fois, nous ne la connaissions peut-être pas, en particulier comment écrire rulesdes règles. Vous pouvez analyser les méthodes d'écriture des objets de ressource tels que clusterrole et clusterrolebinding qui accompagnent le système. Comment l'analyser ? Utilisez toujours les opérations get, describe, -o yaml de kubectl, donc kubectlles utilisateurs les plus basiques doivent bien les maîtriser.

RBACC'est juste Kubernetesun moyen de certification de sécurité, et bien sûr c'est le moyen le plus important maintenant.Je parlerai de Kubernetesla conception de la sécurité dans un article ultérieur.

---