Secrets variables d'environnements et volume config

Secrets

Les Secrets dans Kubernetes sont des objets qui permettent de stocker et de gérer des informations sensibles, telles que des mots de passe, des clés API, des certificats, etc. Contrairement aux ConfigMaps, les Secrets sont conçus pour manipuler des données confidentielles de manière sécurisée.

---

Pourquoi utiliser des Secrets ?

1. Sécurisation des données sensibles : Les Secrets empêchent d'exposer des informations critiques dans le code ou les fichiers de configuration.
2. Encodage Base64 : Les données sont stockées encodées (non chiffrées) en Base64 dans etcd.
3. Intégration avec d'autres ressources Kubernetes : Les Secrets peuvent être utilisés comme variables d'environnement, fichiers montés ou pour l'authentification des conteneurs.

Étape 1 : Créez un Secret et le charger comme env vars

Supposons que vous souhaitiez stocker des informations d'authentification de base de données, telles que le nom d'utilisateur et le mot de passe, dans un Secret. Voici comment vous pouvez le faire :

 

• Charger le secret un à un comme env vars
  • file: secret-vars01.yaml

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: dXNlcm5hbWU=  # "username" encodé en Base64
  password: cGFzc3dvcmQ=  # "password" encodé en Base64

---

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: my-app
    image: debian:latest
    command: ['sh', '-c', 'echo "The app is running!" && env | grep APP_']
    env:
    - name: APP_USERNAME
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: username
    - name: APP_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: password

 

kubectl apply -f secret-vars01.yaml

kubectl get secrets
kubectl logs po/secret-env-pod

 

 

• Charger le secret globalement comme env vars: Pour ne pas encoder en base64 on peut utiliser la clé stringData

apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
type: Opaque
stringData:
  APP_USERNAME: my-username # doit pas etre encodé
  APP_PASSWORD: my-password # doit pas etre encodé"

---

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-pod
spec:
  containers:
  - name: my-app
    image: debian:latest
    command: ['sh', '-c', 'echo "The app is running!" && env | grep APP_']
    envFrom:
    - secretRef:
        name: app-secrets

 

kubectl apply -f secret-vars02.yaml

kubectl get secrets
kubectl logs po/secret-env-pod

 

 

• Charger le secret comme volume

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
stringData:
  APP_USERNAME: my-username # doit pas etre encodé
  APP_PASSWORD: my-password # doit pas etre encodé"

---

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-pod
spec:
  containers:
  - name: my-app
    image: my-app-image
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/secret"
  volumes:
  - name: secret-volume
    secret:
      secretName: my-secret

 

• Docker registry secret

Un Secret Docker (également appelé Secret de registre Docker) est un type particulier de Secret dans Kubernetes qui est utilisé pour stocker les informations d'authentification nécessaires pour accéder à un registre Docker privé. Ces informations d'authentification peuvent inclure le nom d'utilisateur, le mot de passe et parfois d'autres détails pour se connecter à un registre Docker privé afin de pull des images Docker.

 

• • Encodé en base64: cat config.json | base64

# dockerconfigjson.json
{
  "auths": {
    "my-registry.com": {
      "username": "my-username",
      "password": "my-password",
      "email": "my-email@example.com",
      "auth": "base64-encoded-auth"
    }
  }
}

# cat config.json | base64

 

• • Le manifest du secret

apiVersion: v1
kind: Secret
metadata:
  name: my-docker-secret
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: <base64-encoded-docker-config>

 

• metadata: Vous donnez un nom au Secret Docker, par exemple, "my-docker-secret".

• type: Vous spécifiez le type en utilisant "kubernetes.io/dockerconfigjson". Cela indique à Kubernetes que ce Secret contiendra des informations d'authentification pour un registre Docker.

• data: Vous encodez en Base64 le fichier de configuration Docker config.json contenant les informations d'authentification, puis vous l'ajoutez sous la clé ".dockerconfigjson". Vous pouvez utiliser la commande kubectl create secret docker-registry pour créer ce type de Secret à partir d'un fichier config.json.

 

Une fois que vous avez créé le Secret Docker, vous pouvez le référencer dans vos pods ou Deployments pour accéder à un registre Docker privé en spécifiant le nom du Secret dans les spécifications des conteneurs. Par exemple :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app-container
        image: my-registry.com/my-image:latest
      imagePullSecrets:
      - name: my-docker-secret

 

Dans cet exemple, nous avons spécifié le nom du Secret Docker "my-docker-secret" dans la section imagePullSecrets du pod. Cela permet au pod de tirer des images Docker depuis le registre privé en utilisant les informations d'authentification stockées dans le Secret. Assurez-vous que le nom du Secret correspond à celui que vous avez créé.

 Back to top   Étape 2 : Créez un Secret pour les certificat et le monter comme volume

 

• Encodé en base64: cat tls.crt | base64

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: <Base64-encoded certificate>
  tls.key: <Base64-encoded private key>

---
apiVersion: v1
kind: Secret
metadata:
  name: default-token
type: kubernetes.io/service-account-token
data:
  ca.crt: <Base64-encoded certificate>
  token: <Base64-encoded token>

---

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-pod
spec:
  containers:
  - name: my-app
    image: my-app-image
    volumeMounts:
    - name: secret-volume
      mountPath: "/etc/secret/certs"
  volumes:
  - name: secret-volume
    secret:
      secretName: tls-secret

 

Bonnes pratiques

1. Restreindre les accès : Appliquez des contrôles RBAC pour limiter qui peut lire ou modifier les Secrets.
2. Utiliser des outils pour le chiffrement : Contrairement aux ConfigMaps, les Secrets sont encodés en base64 mais non chiffrés par défaut. Il faut donc utiliser un outil comme Vault ou Sealed Secrets pour une gestion plus sécurisée.
3. Séparation des rôles : Placez les Secrets dans des namespaces spécifiques et limitez les permissions.
4. Ne jamais inclure de Secrets en clair dans vos fichiers YAML.