🥇Guide de sécurité dans Kubernetes : authentification, autorisation, audit

Tôt ou tard, la question de la sécurité se pose lors de l'exploitation de tout système : la mise en place de l'authentification, la répartition des droits, l'audit et d'autres tâches. Pour Kubernetes, plusieurs solutions ont déjà été créées qui permettent d'atteindre la conformité même dans des environnements très exigeants… Ce document est consacré aux aspects fondamentaux de la sécurité intégrés dans les mécanismes de base de K8s. Il sera particulièrement utile à ceux qui débutent avec Kubernetes, comme point de départ pour explorer les questions de sécurité.Kubernetes dispose de deux types d'utilisateurs :

Authentification

Service Accounts

— des comptes gérés par l'API Kubernetes ; — des utilisateurs « normaux », gérés par des services externes et indépendants.
Utilisateurs La principale différence entre ces types réside dans le fait qu'il existe des objets spécifiques dans l'API Kubernetes pour les Service Accounts (appelés simplement —

ServiceAccounts ), qui sont liés à un namespace et à un ensemble de données d'autorisation stockées dans le cluster sous forme d'objets de type Secrets. Ces utilisateurs (Service Accounts) sont principalement destinés à gérer les droits d'accès à l'API Kubernetes pour les processus s'exécutant dans le cluster Kubernetes.Les Users ordinaires, en revanche, n'ont pas d'enregistrements dans l'API Kubernetes : leur gestion doit être effectuée par des mécanismes externes. Ils sont destinés aux personnes ou aux processus résidant en dehors du cluster.

Chaque requête à l'API est associée soit à un Service Account, soit à un User, soit est considérée comme anonyme.

Les données d'authentification de l'utilisateur comprennent :

— le nom d'utilisateur (sensible à la casse !) ;

Nom d'utilisateur UID
— une chaîne d'identification machine lisible qui est « plus cohérente et unique que le nom d'utilisateur » ; — la liste des groupes auxquels appartient l'utilisateur ;
Groupes Extra
— des champs supplémentaires pouvant être utilisés par le mécanisme d'autorisation. Kubernetes peut utiliser de nombreux mécanismes d'authentification : certificats X509, jetons Bearer, proxy d'authentification, HTTP Basic Auth. Grâce à ces mécanismes, il est possible de mettre en œuvre une variété de schémas d'autorisation : d'un simple fichier avec des mots de passe à OpenID OAuth2.

De plus, l'utilisation de plusieurs schémas d'autorisation simultanément est autorisée. Par défaut, le cluster utilise :

des jetons de compte de service — pour les Service Accounts ;

X509 — pour les Users.
X509 — pour les utilisateurs.

La question de la gestion des ServiceAccounts dépasse le cadre de cet article, et je recommande à ceux qui souhaitent en savoir plus de commencer par la page de documentation officielle. Nous allons examiner en détail la question des certificats X509.

Certificats pour les utilisateurs (X.509)

La méthode classique pour travailler avec les certificats implique :

génération de la clé :

mkdir -p ~/mynewuser/.certs/
openssl genrsa -out ~/mynewuser.key 2048

génération d'une demande de certificat :

openssl req -new -key ~/mynewuser.key -out ~/mynewuser.csr -subj "/CN=mynewuser/O=company"

traitement de la demande de certificat avec les clés CA du cluster Kubernetes, obtention du certificat utilisateur (pour obtenir le certificat, il est nécessaire d'utiliser un compte ayant accès à la clé de l'autorité de certification du cluster Kubernetes, qui se trouve par défaut dans /etc/kubernetes/pki/ca.key):
```
openssl x509 -req -in ~/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/mynewuser.crt -days 500
```

création du fichier de configuration :

description du cluster (indiquez l'adresse et l'emplacement du fichier de certificat CA de l'installation spécifique du cluster) :
```
kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443
```
ou — comme neoption recommandée — vous pouvez ne pas spécifier le certificat racine (dans ce cas, kubectl ne vérifiera pas la validité de l'api-server du cluster) :
```
kubectl config set-cluster kubernetes --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443
```

ajout d'un utilisateur dans le fichier de configuration :

kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt --client-key=.certs/mynewuser.key

ajout du contexte :

kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

définir le contexte par défaut :

kubectl config use-context mynewuser-context

Après les manipulations ci-dessus, le fichier .kube⁄config aura la configuration suivante :

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

Pour faciliter le transfert de la configuration entre les comptes et les serveurs, il est utile de modifier les valeurs des clés suivantes :

certificate-authority
client-certificate
client-key

Pour cela, vous pouvez encoder les fichiers mentionnés en utilisant base64 et les inscrire dans la configuration, en ajoutant le suffixe -data, c'est-à-dire obtenir certificate-authority-data etc.

Certificats avec kubeadm

Avec la version Kubernetes 1.15 Travailler avec les certificats est devenu beaucoup plus facile grâce à la version alpha de son support dans l'outil kubeadm. Par exemple, voici à quoi pourrait ressembler la génération du fichier de configuration avec les clés utilisateur :

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: Requis adresse publicitaire peut être consultée dans le fichier de configuration de l'api-server, qui est par défaut situé dans /etc/kubernetes/manifests/kube-apiserver.yaml.

Le fichier de configuration résultant sera affiché dans stdout. Il doit être sauvegardé dans ~/.kube/config le compte utilisateur ou dans un fichier spécifié par la variable d'environnement KUBECONFIG.

Approfondir

Pour ceux qui souhaitent approfondir les questions décrites :

un article séparé sur le travail avec les certificats dans la documentation officielle de Kubernetes ;
un bon article de Bitnami, dans lequel la question des certificats est abordée d'un point de vue pratique.
documentation générale sur l'authentification dans Kubernetes.

Autorisation

Un compte autorisé par défaut n'a pas de droits d'action dans le cluster. Pour accorder des permissions, Kubernetes a mis en place un mécanisme d'autorisation.

Jusqu'à la version 1.6, un type d'autorisation appelé ABAC (contrôle d'accès basé sur les attributs) était utilisé dans Kubernetes. Les détails peuvent être trouvés dans la documentation officielle. Actuellement, cette approche est considérée comme obsolète, cependant vous pouvez encore l'utiliser en parallèle avec d'autres types d'autorisation.

Le mode actuel (et plus flexible) de séparation des droits d'accès au cluster s'appelle RBAC (contrôle d'accès basé sur les rôles). Il a été déclaré stable depuis la version Kubernetes 1.8. RBAC met en œuvre un modèle de droits où tout est interdit tant que cela n'est pas explicitement autorisé.
Pour activer RBAC, vous devez démarrer le serveur api Kubernetes avec le paramètre --authorization-mode=RBAC. Les paramètres sont définis dans le manifeste de configuration de l'api-server, qui se trouve par défaut au chemin /etc/kubernetes/manifests/kube-apiserver.yaml, dans la section commande. Cependant, par défaut, RBAC est déjà activé, donc il ne devrait probablement pas y avoir lieu de s'inquiéter : vous pouvez vérifier cela par la valeur authorization-mode (dans le fichier déjà mentionné kube-apiserver.yaml). D'ailleurs, parmi ses valeurs, d'autres types d'autorisation peuvent également apparaître (node, webhook, always allow), mais nous laisserons leur examen en dehors de ce document.

D'ailleurs, nous avons déjà publié article un récit assez détaillé sur les principes et les particularités du travail avec RBAC ; ainsi, je me limiterai à une brève énumération des bases et des exemples.

Pour gérer l'accès dans Kubernetes via RBAC, les entités API suivantes sont utilisées :

Rôle et ClusterRole — rôles qui servent à décrire les droits d'accès :
Rôle permet de décrire les droits dans un espace de noms;
ClusterRole — dans le cadre d'un cluster, y compris pour les objets spécifiques au cluster tels que les nœuds, les urls non-ressources (c'est-à-dire non liés aux ressources Kubernetes — par exemple, /version, /logs, /api*);
RoleBinding et ClusterRoleBinding — sert à lier Rôle et ClusterRole à un utilisateur, un groupe d'utilisateurs ou un ServiceAccount.

Les entités Role et RoleBinding sont limitées à l'espace de noms, c'est-à-dire qu'elles doivent se trouver dans un même espace de noms. Cependant, RoleBinding peut faire référence à ClusterRole, ce qui permet de créer un ensemble de permissions standard et de gérer l'accès à l'aide de celles-ci.

Les rôles décrivent les droits à l'aide d'ensembles de règles, contenant :

groupes API — voir la documentation officielle pour apiGroups et sortie kubectl api-resources;
ressources (resources: pod, namespace, déploiement et autres);
verbes (verbs: set, update etc.).
noms de ressources (resourceNames) — pour le cas où il est nécessaire d'accorder l'accès à une ressource spécifique, et non à toutes les ressources de ce type.

Une analyse plus détaillée de l'autorisation dans Kubernetes peut être trouvée sur la page la documentation officielle. Au lieu de cela (ou plutôt — en complément de cela), je vais donner des exemples qui illustrent son fonctionnement.

Exemples d'entités RBAC

Simplicité Rôle, permettant d'obtenir la liste et le statut des pods et de les surveiller dans l'espace de noms target-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

Exemple ClusterRole, ce qui permet d'obtenir la liste et le statut des pods et de les surveiller dans tout le cluster :

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # la section "namespace" n'est pas présente, car ClusterRole couvre tout le cluster
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Exemple RoleBinding, ce qui permet à l'utilisateur mynewuser de « lire » les pods dans l'espace de noms my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # le nom d'utilisateur est sensible à la casse !
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # cela doit être “Role” ou “ClusterRole”
  name: pod-reader # nom de Role, qui se trouve dans le même namespace,
                   # ou le nom de ClusterRole, dont l'utilisation
                   # est autorisée à l'utilisateur
  apiGroup: rbac.authorization.k8s.io

Audit des événements

De manière schématique, l'architecture de Kubernetes peut être présentée comme suit :

Le composant clé de Kubernetes, responsable du traitement des demandes, est api-server. Toutes les opérations sur le cluster passent par lui. Pour en savoir plus sur ces mécanismes internes, vous pouvez lire l'article «Que se passe-t-il dans Kubernetes lors de l'exécution de kubectl run ?».

L'audit système est une fonctionnalité intéressante dans Kubernetes qui est désactivée par défaut. Elle permet de journaliser toutes les demandes adressées à l'API Kubernetes. Comme on peut s'en douter, c'est par cette API que toutes les actions liées au contrôle et à la modification de l'état du cluster sont effectuées. Une bonne description de ses capacités peut être trouvée dans K8s. Je vais essayer d'expliquer le sujet de manière plus simple. la documentation officielle K8s. Je vais maintenant essayer d'expliquer le sujet de manière plus simple.

Alors, Pour activer l'audit, nous devons fournir au conteneur dans le api-server trois paramètres obligatoires, dont je parlerai plus en détail ci-dessous :

--audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
--audit-log-path=/var/log/kube-audit/audit.log
--audit-log-format=json

En plus de ces trois paramètres nécessaires, il existe de nombreux paramètres supplémentaires concernant l'audit : de la rotation des journaux aux descriptions des webhooks. Exemple de paramètres de rotation des journaux :

--audit-log-maxbackup=10
--audit-log-maxsize=100
--audit-log-maxage=7

Mais nous ne nous attarderons pas plus en détail là-dessus — toutes les informations peuvent être trouvées dans la documentation de kube-apiserver.

Comme mentionné précédemment, tous les paramètres sont définis dans le manifeste de configuration du api-server (par défaut /etc/kubernetes/manifests/kube-apiserver.yaml), dans la section commande. Revenons aux 3 paramètres obligatoires et examinons-les :

audit-policy-file — le chemin vers le fichier YAML contenant la description de la politique d'audit. Nous y reviendrons, mais je souligne que le fichier doit être lisible par le processus du api-server. Il est donc nécessaire de le monter à l'intérieur du conteneur, ce qui peut être fait en ajoutant le code suivant dans les sections appropriées de la configuration :
```
  volumeMounts:
    - mountPath: /etc/kubernetes/policies
      name: policies
      readOnly: true
  volumes:
  - hostPath:
      path: /etc/kubernetes/policies
      type: DirectoryOrCreate
    name: policies
```

audit-log-path — le chemin vers le fichier de journal. Ce chemin doit également être accessible au processus du api-server, donc nous décrivons de la même manière son montage :

  volumeMounts:
    - mountPath: /var/log/kube-audit
      name: logs
      readOnly: false
  volumes:
  - hostPath:
      path: /var/log/kube-audit
      type: DirectoryOrCreate
    name: logs

audit-log-format — le format du journal d'audit. Par défaut, c'est json, mais un format texte obsolète est également disponible (legacy).

Politique d'audit

Maintenant, concernant le fichier mentionné décrivant la politique de journalisation. La première notion de politique d'audit, c'est le niveau, niveau de journalisation. Il peut être l'un des suivants :

TSSAA — ne pas journaliser ;
Metadata — journaliser les métadonnées de la demande : utilisateur, heure de la demande, ressource cible (pod, namespace, etc.), type d'action (verb), etc. ;
Request — journaliser les métadonnées et le corps de la demande ;
RequestResponse — journaliser les métadonnées, le corps de la demande et le corps de la réponse.

Les deux derniers niveaux (Request et RequestResponse) ne consignent pas les requêtes qui n'ont pas accédé aux ressources (les accès aux URL dites non-ressources).

De plus, toutes les requêtes passent par plusieurs étapes:

RequestReceived — étape où la requête a été reçue par le gestionnaire et n'a pas encore été transmise à la chaîne de gestionnaires ;
ResponseStarted — les en-têtes de réponse ont été envoyés, mais le corps de la réponse n'a pas encore été envoyé. Cela est généré pour les requêtes prolongées (par exemple, regarder);
ResponseComplete — le corps de la réponse a été envoyé, aucune information supplémentaire ne sera envoyée ;
Panic — des événements sont générés lorsqu'une situation anormale est détectée.

Pour ignorer certaines étapes, vous pouvez utiliser omitStages.

Dans le fichier de politique, nous pouvons décrire plusieurs sections avec différents niveaux de journalisation. La première règle appropriée trouvée dans la description de la politique sera appliquée.

Le démon kubelet surveille les modifications du manifeste avec la configuration du serveur api et redémarre le conteneur avec le serveur api lorsqu'il détecte de telles modifications. Mais il y a un détail important : les modifications dans le fichier de politique seront ignorées par lui. Après avoir effectué des modifications dans le fichier de politique, il faudra redémarrer le serveur api manuellement. Étant donné que le serveur api est lancé comme pod statique, l'équipe kubectl delete ne saura pas le redémarrer. Il faudra manuellement exécuter docker stop sur les kube-masters où la politique d'audit a été modifiée :

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

Lors de l'activation de l'audit, il est important de se rappeler que la charge sur le kube-apiserver augmente. En particulier, la consommation de mémoire pour stocker le contexte des requêtes augmente. L'enregistrement dans le journal commence seulement après l'envoi de l'en-tête de réponse. La charge dépend également de la configuration de la politique d'audit.

Exemples de politiques

Analysons la structure des fichiers de politique à travers des exemples.

Voici un fichier simple policy, pour enregistrer tout au niveau Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

Dans la politique, vous pouvez spécifier une liste d'utilisateurs (Utilisateurs et ), qui sont liés à un namespace et à un ensemble de données d'autorisation stockées dans le cluster sous forme d'objets de type Secrets. Ces utilisateurs (Service Accounts) sont principalement destinés à gérer les droits d'accès à l'API Kubernetes pour les processus s'exécutant dans le cluster Kubernetes.) et de groupes d'utilisateurs. Par exemple, voici comment nous ignorerons les utilisateurs système tout en enregistrant le reste au niveau Request:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

Il est également possible de décrire des cibles :

noms d'espaces (namespaces);
verbes (verbs: obtenir, update, supprimer et autres) ;
ressources (resources, à savoir : pod, configmaps et autres.) et groupes de ressources (apiGroups).

Attention! Les ressources et groupes de ressources (groupes API, c'est-à-dire apiGroups), ainsi que leurs versions installées dans le cluster, peuvent être obtenus à l'aide des commandes :

kubectl api-resources
kubectl api-versions

La politique d'audit suivante est fournie à titre de démonstration des meilleures pratiques dans la documentation Alibaba Cloud:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Ne pas enregistrer l'étape RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Ne pas enregistrer les événements considérés comme mineurs et non dangereux :
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # c'est le groupe api avec un nom vide, relatif aux
                  # ressources de base Kubernetes, appelées “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Ne pas enregistrer les accès aux URL en lecture seule :
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Ne pas enregistrer les messages relatifs au type de ressources “événements” :
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Les ressources de type Secret, ConfigMap et TokenReview peuvent contenir des données sensibles,
  # donc nous enregistrons uniquement les métadonnées des requêtes qui leur sont liées
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Les actions de type get, list et watch peuvent être gourmandes en ressources ; ne pas les enregistrer
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Niveau de journalisation par défaut pour les ressources API standards
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Niveau de journalisation par défaut pour toutes les autres requêtes
  - level: Metadata

Un autre bon exemple de politique d'audit — le profil utilisé dans GCE.

Pour une réponse rapide aux événements d'audit, il est possible de décrire un webhook. Cette question est abordée dans la documentation officielle, je laisserai cela de côté dans cet article.

Résultats

Cet article offre un aperçu des mécanismes de sécurité de base dans les clusters Kubernetes, permettant de créer des comptes utilisateurs personnalisés, de séparer leurs droits et d'enregistrer leurs actions. J'espère qu'il sera utile à ceux qui ont rencontré de telles questions, que ce soit en théorie ou en pratique. Je vous recommande également de consulter la liste des autres ressources sur la sécurité dans Kubernetes, mentionnée dans le 'P.S.', car vous y trouverez peut-être des détails nécessaires sur les problèmes qui vous préoccupent.

P.S.

Lisez aussi dans notre blog :

Source : habr.com

L'alphabet de la sécurité dans Kubernetes : authentification, autorisation, audit