External Secrets Operator

External Secrets Operator s'intègre à Devolutions Server pour la gestion des secrets.

Les valeurs dans ce guide (p. ex., your-application-id) sont des espaces réservés ; remplacez-les par les valeurs spécifiques à votre environnement.

Authentification

L'authentification à Devolutions Server utilise les identifiants Application ID et Application secret.

Création d'une identité d'application dans Devolutions Server

1. Connectez-vous à l'interface Web de votre Devolutions Server.
2. Accédez à Administration – Applications identities.
3. Cliquez sur Ajouter (+) pour créer une nouvelle application.
4. Configurez l'application avec les autorisations requises pour accéder aux coffres et aux entrées souhaités.
5. Enregistrez l'Application ID et l'Application secret.

Création du secret Kubernetes

Créez un secret Kubernetes contenant vos identifiants Devolutions Server à l'aide du script suivant :

kubectl create secret generic dvls-credentials \
  --from-literal=app-id="your-application-id" \
  --from-literal=app-secret="your-application-secret"

Création d'un SecretStore

apiVersion: external-secrets.io/v1
kind: SecretStore
metadata:
  name: dvls-store
  namespace: default
spec:
  provider:
    dvls:
      serverUrl: 'https://devolutions-server.example.com'
      vault: 'my-vault'
      auth:
        secretRef:
          appId:
            name: dvls-credentials
            key: app-id
          appSecret:
            name: dvls-credentials
            key: app-secret

Champ	Description
serverUrl	L'URL de l'instance Devolutions Server (p. ex., https://devolutions-server.example.com)
vault	Le nom ou l'UUID du coffre depuis lequel récupérer les secrets. Lorsqu'il est omis, le coffre doit être spécifié dans la clé du secret en utilisant le format hérité <vault-id>/<entry-id>. Ce champ est facultatif.
insecure	Définissez à true pour autoriser les connexions HTTP non sécurisées. Non recommandé en production. Ce champ est facultatif.
auth.secretRef.appId	Référence au secret contenant l'Application ID.
auth.secretRef.appSecret	Référence au secret contenant l'Application secret.

Pour ClusterSecretStore, assurez-vous de spécifier le namespace dans les références de secret.

Référencement des secrets

Les entrées peuvent être référencées par UUID ou par nom :

Format	Exemple
UUID de l'entrée	7c9e6679-7425-40de-944b-e07fc1f90ae7
Nom de l'entrée	db-credentials
Nom de l'entrée avec chemin de dossier	infrastructure/databases/db-credentials
Chemin de dossier avec barres obliques inverses	infrastructure\databases\db-credentials

Le coffre est configuré dans le champ vault du SecretStore (nom ou UUID), de sorte que la clé n'a besoin d'identifier que l'entrée.

Chemins de dossier

Si une entrée se trouve dans un dossier, vous pouvez inclure le chemin du dossier avant le nom de l'entrée. Les barres obliques (/) et les barres obliques inverses (\) sont acceptées comme séparateurs de chemin :

folder/subfolder/entry-name
folder\subfolder\entry-name

Lorsque vous utilisez des barres obliques inverses dans YAML, vous devez les échapper avec une double barre oblique inverse (\\) :

key: "folder\\subfolder\\entry-name"

Les barres obliques ne nécessitent pas d'échappement et sont recommandées pour leur simplicité.

Les noms d'entrée contenant des barres obliques (/) ou des barres obliques inverses (</code>) ne sont pas pris en charge avec les recherches par nom, car ces caractères sont interprétés comme des séparateurs de chemin. Utilisez plutôt l'UUID de l'entrée.

Le chemin du dossier est facultatif. Sans chemin, le fournisseur effectue une recherche dans tous les dossiers du coffre. Si plusieurs entrées partagent le même nom dans des dossiers différents, vous pouvez soit spécifier le chemin du dossier, soit utiliser l'UUID de l'entrée pour lever l'ambiguïté.

Les recherches par nom résolvent le nom en UUID au moment de l'exécution via un appel API. Si plusieurs entrées de type identifiants correspondent, une erreur est retournée. Pour les scénarios à forte sollicitation en écriture (opérations PushSecret fréquentes), privilégiez les références par UUID afin d'éviter la recherche supplémentaire par opération.

Vous pouvez trouver les UUID dans l'interface Web de Devolutions Server en affichant les propriétés de l'entrée.

Types d'identifiants pris en charge

Devolutions Server prend en charge plusieurs types d'identifiants. Le fournisseur associe chaque type à des propriétés spécifiques :

Type d'identifiants	Type d'entrée Devolutions Server	Propriétés disponibles
Default	Credential	username, password, domain
Access Code	Secret	password
API Key	Credential	api-id, api-key, tenant-id
Azure Service Principal	Credential	client-id, client-secret, tenant-id
Connection String	Credential	connection-string
Private Key	Credential	username, password, private-key, public-key, passphrase

Toutes les entrées incluent également les propriétés de métadonnées entry-id et entry-name.

Lorsqu'aucune property n'est spécifiée, le champ password est retourné par défaut.

Dans l'interface Web de Devolutions Server, les entrées de type « Secret » apparaissent comme un type d'entrée distinct et sont associées en interne au sous-type d'identifiants Access Code.

Exemples

Récupération de propriétés individuelles

Pour récupérer des propriétés spécifiques d'une entrée d'identifiants :

---
# Fetch a single property from a credential entry by name
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: dvls-store
  target:
    name: database-secret
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: 'db-credentials'
        property: username
    - secretKey: password
      remoteRef:
        key: 'db-credentials'
        property: password
---
# Fetch all fields from a credential entry with folder path
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: api-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: dvls-store
  target:
    name: api-secret
    creationPolicy: Owner
  dataFrom:
    - extract:
        key: 'infrastructure/apis/my-api-key'
---
# Fetch a Secret entry (Access Code type) by UUID
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: app-secret
spec:
  refreshInterval: 1h
  secretStoreRef:
    kind: SecretStore
    name: dvls-store
  target:
    name: app-secret
    creationPolicy: Owner
  data:
    - secretKey: secret
      remoteRef:
        key: '<entry-uuid>'
        property: password

Utilisation de dataFrom pour extraire tous les champs

Lors de l'utilisation de dataFrom.extract, toutes les propriétés disponibles de l'entrée d'identifiants seront synchronisées avec le secret Kubernetes.

Publication de secrets

Le fournisseur Devolutions Server prend en charge la publication de secrets vers Devolutions Server :

apiVersion: external-secrets.io/v1alpha1
kind: PushSecret
metadata:
  name: push-to-dvls
spec:
  refreshInterval: 1h
  secretStoreRefs:
    - name: dvls-store
      kind: SecretStore
  selector:
    secret:
      name: my-k8s-secret
  data:
    - match:
        secretKey: password
        remoteRef:
          # When vault is set in the SecretStore, remoteKey is the entry name
          # (or path/name). Without vault, use the legacy 'vault-uuid/entry-uuid' format.
          remoteKey: 'db-credentials'

Remarque : La publication d'un secret met à jour le champ mot de passe d'une entrée existante. L'entrée doit déjà exister dans Devolutions Server.

Limitations

• GetAllSecrets : L'opération find pour la découverte de secrets n'est pas actuellement prise en charge.
• Certificats CA personnalisés : Les certificats TLS personnalisés pour les instances Devolutions Server auto-signées ne sont pas encore pris en charge. Utilisez la variable d'environnement SSL_CERT_FILE comme solution de contournement.
• Entrées de type certificat : Les types d'entrées de certificat (Document/Certificate) ne sont pas actuellement pris en charge. Seules les entrées de type Credential sont prises en charge.

Dépannage

Erreurs d'authentification

Si vous recevez des erreurs d'authentification :

1. Vérifiez que l'Application ID et l'Application secret sont corrects.
2. Assurez-vous que l'application dispose des autorisations nécessaires dans Devolutions Server.
3. Vérifiez que l'URL du serveur Devolutions Server est accessible depuis votre cluster Kubernetes.

Entrée introuvable

Si une entrée est introuvable :

1. Vérifiez que les références au coffre et à l'entrée sont correctes (UUID ou nom).
2. Assurez-vous que l'application dispose au minimum d'un accès en lecture au coffre.
3. Vérifiez que l'entrée existe et est de type Credential ou Secret.
4. Assurez-vous que l'application dispose au minimum des autorisations de lecture, d'affichage du mot de passe et de connexion (exécution) sur l'entrée.

Plusieurs entrées trouvées

Si vous recevez une erreur « multiple entries found » lors de l'utilisation de références par nom, cela signifie que plusieurs entrées d'identifiants partagent le même nom dans le coffre. Utilisez l'UUID de l'entrée plutôt que le nom pour cibler l'entrée correcte.