Comment gérer les secrets dans Openshift ?

La gestion des secrets consiste à sécuriser le cycle de vie des identifiants, jetons, mots de passe et autres informations sensibles en appliquant de manière cohérente les politiques de sécurité. Pour réaliser ces tâches, Kubernetes Secrets n’est pas le meilleur de sa catégorie. En effet, il n’offre qu’un encodage base64 pour les données sensibles contenues dans une définition de secret, sans chiffrement.

La meilleure solution reste d’utiliser un service de gestion de clés. Dans cet article, nous verrons comment récupérer et utiliser ces secrets dans le service de gestion de clés externe.

Vous souhaitez apprendre le déploiement et l’orchestration de conteneurs applicatif ? Notre formation Openshift vous apprendra le fonctionnement de l’un des outils PaaS les plus performants du marché. À l’issue de cette formation, vous saurez créer et gérer des services conteneurisés et multiconteneurisés.

L’équipe Ambient IT

Configuration du coffre

Pour plus de simplicité, le Hashicorp Vault doit être configuré en mode « dev » sur Openshift. Vous devez d’abord ajouter le dépôt graphique Helm correspondant et créons un projet OpenShift nommé vault.

$ helm repo add hashicorp https://helm.releases.hashicorp.com
$ oc new-project vault

Vous pouvez ensuite créer un fichier contenant les références aux images du conteneur Vault à utiliser (ici « override-values.yaml ») et les paramètres « global.openshift » et « server.dev.enabled » à « true » pour activer Vault en mode « dev ».

global:
  openshift: true

injector:
  image:
    repository: "registry.connect.redhat.com/hashicorp/vault-k8s"
    tag: "1.2.1-ubi"

  agentImage:
    repository: "registry.connect.redhat.com/hashicorp/vault"
    tag: "1.13.1-ubi"

server:
  image:
    repository: "registry.connect.redhat.com/hashicorp/vault"
    tag: "1.13.1-ubi"
  dev:
    enabled: true

Vous pouvez ensuite installer Vault en utilisant les paramètres définis dans le fichier « override-values.yaml » en exécutant la commande :

$ helm install vault hashicorp/vault -f override-values.yaml

Vous devriez voir apparaitre le message suivant :

NAME: vault
LAST DEPLOYED: date/heure/année
NAMESPACE: vault
STATUS: deployed
REVISION: 1
NOTES:
Thank you for installing HashiCorp Vault!

Vérifiez bien que 2 pods ont bien été créés dans le « vault »

Configurer l’opérateur de secrets externe

Il est maintenant temps de configurer l’External Secret Operator (ESO) dans un projet Openshift. Le projet sera appelé external-secrets.

$ oc new-project external-secrets
$ helm repo add external-secrets https://charts.external-secrets.io
$ helm install external-secrets external-secrets/external-secrets

Injecter le secret dans l’application avec le ESO

Lorsque le Vault et le ESO ont été configurés, vous pouvez injecter le secret dans le namespace spécifique de l’application où il doit être utilisé. Pour cela, des instances ExternalSecret et SecretStore doivent être configurées dans le namespace.

Un secretstore est un espace personnalisé dans le namespace. Son rôle est de spécifier comment accéder au service ESO. Externalsecret définit lui quelles data doivent être récupérées et comment elles doivent être stockées.

Pour définir un secretstore avec les paramètres requis pour se connecter au serveur Vault configuré en mode dev. En mode dev, le serveur vault fonctionne sur la mémoire et commence à être initialisé et descellé avec une clé spécifique. Un token root est créé automatiquement dans le cadre de l’initialisation et peut être utilisé pour se connecter au serveur Vault.

$ oc logs vault-0 -n vault | grep 'Root Token'
Root Token: root

Vous pouvez maintenant faire un encodage base64 du token root du serveur Vault dont la valeur est root et créer un secret à partir de ce jeton. Il doit être référencé comme le token d’authentification requis dans le secretstore.

$ echo 'root' | base64
cm9vdAo=

$ cat <<EOF > vault-token.yaml
apiVersion: v1
kind: Secret
metadata:
  name: vault-token
data:
  token: cm9vdA== 
EOF

$ oc new-project application 
$ oc apply -f vault-token.yaml -n application

Créez maintenant un secretstore référençant le service Vault et le token créé précédemment.

$ cat <<EOF > secretstore-vault.yaml
apiVersion: external-secrets.io/v1alpha1
kind: SecretStore
metadata:
  name: secretstore-vault
spec:
  provider:
    vault:
      server: "http://vault.vault.svc.cluster.local:8200"
      path: "secret"
      version: "v2"
      auth:
        tokenSecretRef:
          name: "vault-token"
          key: "token"
EOF

$ oc apply -f secretstore-vault.yaml -n application

Enfin, créez un ExternalSecret pour définir le paramètre secret qui doit être auto-injecté dans le namespace de l’application. Vous devez ensuite créer un secret qui s’injectera automatiquement dans le namespace de l’application contenant une propriété nommée password avec une valeur comme « my-secret-password ».

$ cat <<EOF > externalsecret-vault.yaml
apiVersion: external-secrets.io/v1alpha1
kind: ExternalSecret
metadata:
  name: externalsecret-vault
spec:
  refreshInterval: "15s"
  secretStoreRef:
    name: secretstore-vault
    kind: SecretStore
  target:
    name: secret-from-vault
  data:
  - secretKey: password
    remoteRef:
      key: secret/app/config
      property: password
EOF

$ oc apply -f externalsecret-vault.yaml -n application

Dans cet exemple, l’intervalle de rafraîchissement est défini sur 15 secondes. L’ESO rafraîchira/réconciliera automatiquement le secret pour toutes les mises à jour susceptibles d’être apportées au secret défini dans le coffre-fort. Par exemple, si vous changez la valeur du mot de passe dans le serveur vault, il sera automatiquement actualisé dans le namespace de l’application dans un délai de 15s.

Vous savez maintenant injecter automatiquement un secret dans le vault à l’aide d’un ESO.