Comment gérer les utilisateurs Linux avec Kubernetes?

Question

Je souhaite sécuriser mes clusters avec SecurityContext.RunAsUser. La question est simple: quel utilisateur dois-je utiliser?

Je sais que l'utilisateur avec l'UID 1001 (par exemple) à l'intérieur d'un conteneur est l'utilisateur avec l'UID 1001 sur l'hôte. Dois-je donc créer un utilisateur avec l'UID 1001 appelé pod_usersur tous mes hôtes et forcer tous les pods à utiliser cet utilisateur? Ou devrais-je vérifier qu'aucun utilisateur ne possède cet UID sur tous mes hôtes? Je n'ai pas trouvé de guide des meilleures pratiques à ce sujet.

J'ai le même type de question sur le Dockerfile: dois-je déclarer un utilisateur dans le Dockerfile avec un UID spécifique et le réutiliser SecurityContext.RunAsUser? Certaines images officielles fonctionnent avec un utilisateur codé en dur spécifique dans Dockerfile, et d'autres fonctionnent en tant que personne. J'ai trouvé cet article intéressant mais il n'y a pas de réponse claire: Kubernetes: gestion des utilisateurs Linux .

Answer 1

Ma recommandation idéale ici serait:

• Votre Dockerfile RUN adduserpour créer un utilisateur non root et le basculer USERvers cet utilisateur après avoir effectué toute l'installation du logiciel
• Vous n'avez pas besoin de spécifier explicitement un ID utilisateur dans la configuration Kubernetes
• Peu importe le nom d'utilisateur ou l'ID numérique, ou s'il s'agit du même ID utilisateur qui existe dans un autre conteneur ou sur l'hôte, du moment que l'uid numérique n'est pas 0

Le seul endroit où il y a un problème pratique est si le conteneur essaie de stocker des données dans un volume. Encore une fois, le cas idéal serait d'éviter cela entièrement; préférez utiliser une base de données ou un stockage en nuage si cela est possible.

Si vous devez utiliser un volume local, vous pouvez spécifiquement configurer une stratégie de sécurité avec un fichier supplémentaire fsGroup:. Il s'agit d'un ID de groupe numérique arbitraire (et non d'un ID utilisateur) qui possédera les fichiers du volume et qui sera également ajouté à la liste de groupes pour le processus de conteneur principal.

apiVersion: v1
kind: Pod
spec:
  securityContext:
    fsGroup: 12345  # or any numeric gid

N'utilisez pas du tout des hostPathvolumes: vous ne pouvez pas garantir que le même contenu sera sur chaque nœud si le pod est replanifié, et si le nœud échoue, le contenu qui ne vit que sur ce nœud sera perdu.