web-dev-qa-db-fra.com

Comment monter un volume avec un UID spécifique dans Kubernetes Pod?

Donc, j'essaie de faire fonctionner Nexus à partir de l'image this dans Kubernetes, mais cela échoue avec:

mkdir: cannot create directory '../sonatype-work/nexus3/log': Permission denied
mkdir: cannot create directory '../sonatype-work/nexus3/tmp': Permission denied
Java HotSpot(TM) 64-Bit Server VM warning: Cannot open file ../sonatype-work/nexus3/log/jvm.log due to No such file or directory

D'après la documentation, il est indiqué que le processus s'exécute avec l'UID 200 et que le volume doit être monté avec ces autorisations:

A persistent directory, /nexus-data, is used for configuration,
logs, and storage. This directory needs to be writable by the Nexus
process, which runs as UID 200.

J'ai essayé de parcourir la documentation pour trouver un moyen de monter le volume avec ces autorisations, mais je n'ai trouvé aucun moyen de le faire.

Est-ce que quelqu'un sait si vous pouvez spécifier dans la configuration pour le PVC/PV ou le déploiement avec quel UID pour monter le volume? Si c'est le cas, comment?

permissionskubernetesdisk-volumepv
14
srkiNZ84

Il n'y a aucun moyen de définir le UID en utilisant la définition de Pod, mais Kubernetes enregistre le UID du volume source.

Ainsi, vous pouvez définir le UID par InitContainer, qui se lance avant le conteneur principal, il suffit de l'ajouter au chemin containers du Deployment:

initContainers:
- name: volume-mount-hack
  image: busybox
  command: ["sh", "-c", "chown -R 200:200 /nexus"]
  volumeMounts:
  - name: <your nexus volume>
    mountPath: /nexus
30
Anton Kostenko

Comme Anton l'a dit, bien que nous ne puissions pas définir l'UID en utilisant la définition de Pod. Voici une autre solution de contournement pour ce sujet.

Veuillez vous référer au document officiel de Kubernetes Configurer un contexte de sécurité pour un pod ou un conteneur

La définition de pod que j'ai utilisée:

apiVersion: v1
kind: Pod
metadata:
  name: nexus3
  labels:
    app: nexus3
spec:
  securityContext:
    fsGroup: 200
  volumes:
  - name: nexus-data-vol
    emptyDir: {}
  containers:
  - name: nexus3-container
    image: sonatype/nexus3
    volumeMounts:
    - name: nexus-data-vol
      mountPath: /nexus-data

La définition du service:

apiVersion: v1
kind: Service
metadata:
  name: nexus3-service
spec:
  type: NodePort
  ports:
  - port: 8081
    nodePort: 30390
    protocol: TCP
    targetPort: 8081
  selector:
    app: nexus3

Et puis créez un pod et un service sans aucune autorisation refusée ou autres erreurs:

# kubectl create -f nexus3.yaml
# kubectl create -f nexus3-svc.yaml

Essayez de vous connecter au conteneur Nexus3 et vérifiez le propriétaire/l'autorisation de/nexus-data:

# kubectl exec -it nexus3 -- sh
sh-4.2$ ls -ld /nexus-data/
drwxrwsrwx 16 root nexus 4096 Mar 13 09:00 /nexus-data/
sh-4.2$

Comme vous pouvez le voir, le répertoire appartient à root: nexus, et vous pouvez également vérifier les fichiers dans le répertoire:

sh-4.2$ cd /nexus-data/
sh-4.2$ ls -l
total 72
drwxr-sr-x   3 nexus nexus  4096 Mar 13 09:00 blobs
drwxr-sr-x 269 nexus nexus 12288 Mar 13 08:59 cache
drwxr-sr-x   8 nexus nexus  4096 Mar 13 09:00 db
drwxr-sr-x   3 nexus nexus  4096 Mar 13 09:00 elasticsearch
drwxr-sr-x   3 nexus nexus  4096 Mar 13 08:59 etc
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 generated-bundles
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 instances
drwxr-sr-x   3 nexus nexus  4096 Mar 13 08:59 javaprefs
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 kar
drwxr-sr-x   3 nexus nexus  4096 Mar 13 08:59 keystores
-rw-r--r--   1 nexus nexus     8 Mar 13 08:59 lock
drwxr-sr-x   2 nexus nexus  4096 Mar 13 09:00 log
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 orient
-rw-r--r--   1 nexus nexus     5 Mar 13 08:59 port
drwxr-sr-x   2 nexus nexus  4096 Mar 13 08:59 restore-from-backup
drwxr-sr-x   7 nexus nexus  4096 Mar 13 09:00 tmp
sh-4.2$ touch test-file
sh-4.2$ ls -l test-file
-rw-r--r-- 1 nexus nexus 0 Mar 13 09:13 test-file
sh-4.2$ mkdir test-dir
sh-4.2$ ls -l test-dir
total 0
sh-4.2$ ls -ld test-dir
drwxr-sr-x 2 nexus nexus 4096 Mar 13 09:13 test-dir

C'est la puissance de SetGID :)

Vérifions maintenant que le service fonctionne ou non. J'utilise minikube pour exécuter un cluster kubernetes:

chris@XPS-13-9350 ~ $ minikube service nexus3-service --url
http://192.168.39.95:30390
chris@XPS-13-9350 ~ $ curl -u admin:admin123 http://192.168.39.95:30390/service/metrics/ping
pong

Le service fonctionne comme prévu.

8
chemi0213

Concernant Torsten Bronger 's comment , lorsque vous configurez ConfigMaps et Secrets dans le tableau des volumes dans la spécification de pod, vous pouvez spécifier les autorisations pour autoriser l'accès souhaité à l'aide du defaultMode, donc bien que vous ne puissiez pas définir la propriété du groupe et de l'utilisateur, vous pouvez autoriser les processus du module à lire les fichiers de ces montages. Écrire sur une carte secrète ou config n'a pas vraiment de sens et le mode d'autorisation par défaut est 755 de toute façon, donc la lecture ne devrait pas être un problème pour n'importe quel utilisateur.

0
David Dooling