web-dev-qa-db-fra.com

Modification du propriétaire de fichier par défaut et du propriétaire de groupe des fichiers secrets kubernetes montés sur des volumes projetés

Je suis nouveau sur K8S. J'ai un fichier yaml qui génère des secrets kubernetes montés sur des volumes projetés. Lors de l'exécution, j'ai constaté que les fichiers secrets (emballés avec des secrets) affichent "root" en tant que propriétaire du fichier et propriétaire du groupe. Je souhaite remplacer le propriétaire du fichier et le propriétaire du groupe par le même utilisateur spécifique (disons 450).

J'ai essayé d'utiliser "chown" depuis le conteneur init (essayé mais échoué), mais j'ai eu une erreur en disant "système de fichiers en lecture seule" et je n'ai pas pu modifier le propriétaire du fichier et du groupe. Je ne veux pas utiliser "fsGroup" sous securitycontext. J'ai observé que l'option "mode:" sous "items" se comporte de manière imprévisible lorsque fsGroup est utilisé.

Existe-t-il un moyen de modifier le propriétaire par défaut du fichier et du groupe des fichiers secrets kubernetes montés via les volumes projetés?

Je fournis l'exemple de code ci-dessous. Supposons que je veuille changer le propriétaire du fichier et du groupe du fichier "mot de passe" (sous 'mysecret2') dans l'exemple ci-dessous. comment y parvenir?

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: password
              mode: 511
kubernetesmounted-volumeskubernetes-secrets
12
user_2011

Pour autant que je sache, il n'y a aucun moyen de changer l'UID du propriétaire pour des secrets.

Une solution de contournement consiste à copier un secret dans un fichier normal, puis à modifier son propriétaire et son mode, comme ceci:

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    command: |
      - "/bin/bash"
      - "-exc"
        cp /etc/secrets-mount/*_pgpass /etc/secrets
        chown my-user /etc/*_pgpass
        chmod 600 /etc/*_pgpass
        exec su-exec my-user /entrypoint.sh
    volumeMounts:
    - name: secrets
      mountPath: /etc/secrets-mount/

....
9
Alexey Novgorodov

Comme l'a dit Alexey, ce n'est pas possible pour le moment, tant que github.com/kubernetes/kubernetes/issues/81089 n'est pas terminé.

Sa solution fonctionne parfaitement, sauf si vous avez securityContraint.runAsNonRoot set, auquel cas le conteneur n'aura pas de droits sur le secret.

Dans mon cas, j'ai dû faire ce qui suit:

apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      ##########################################
      #         Volumes definitions
      volumes:
      - name: key-volume
        emptyDir:
          sizeLimit: "8k"
      - name: root-owned-key-volume
        secret:
          secretName: my-secret
          items:
            - key: a_key_file
              path: a_key_file
              mode: 0600
      ##########################################
      #         initContainers definitions
      initContainers:
        - name: set-key-ownership
          image: Alpine:3.6
          command: ["sh", "-c", "cp /root-key/* /key && chown -R 33:33 /key"]
          volumeMounts:
          - mountPath: /key
            name: key-volume
          - mountPath: /root-key
            name: root-owned-key-volume
      ##########################################
      #         Containers definitions
      containers:
      - name: my-main-container
        (...)
        securityContext:
          runAsNonRoot: true
          runAsUser: 33
        (...)
        volumeMounts:
        - mountPath: /key
          name: key-volume

Fondamentalement, sachant qu'il est impossible de changer la propriété du fichier secret, un initContainer le copiera dans un autre dossier temporaire et changera la propriété de ce nouveau fichier.

Brut, mais au moins, ça marche.

1
Orabîg