External Secrets Operator

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

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

Authentification

L'authentification de Devolutions Server utilise les identifiants ID d'application et Secret d'application.

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

1. Connectez-vous à l'interface Web de votre Devolutions Server.

2. Naviguez vers Administration – Identités d'applications.

3. Cliquez sur Ajouter (+) pour créer une nouvelle application.

4. Configurez l'application avec les permissions requises pour accéder aux coffres et aux entrées désirés.

5. Enregistrez l'ID d'application et le Secret d'application.

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 à partir duquel récupérer les secrets. Si omis, le coffre doit être spécifié dans la clé du secret en utilisant l'ancien format <vault-id>/<entry-id>. Ce champ est optionnel.
insecure	Définir à true pour permettre les connexions HTTP en clair. Non recommandé en production. Ce champ est optionnel.
auth.secretRef.appId	Référence au secret contenant l'ID d'application.
auth.secretRef.appSecret	Référence au secret contenant le Secret d'application.

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

Référencement des secrets

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

Format	Exemple
UUID d'entrée	7c9e6679-7425-40de-944b-e07fc1f90ae7
Nom d'entrée	db-credentials
Nom d'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), donc la clé n'a qu'à identifier 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 n'ont pas besoin d'être échappées et sont recommandées pour la simplicité.

Les noms d'entrée contenant des barres obliques (/) ou des barres obliques inverses (</code>) are not supported with name-based lookups, as those characters are interpreted as path separators. Use the entry UUID instead.

Le chemin du dossier est optionnel. Sans chemin, le fournisseur effectue une recherche dans tous les dossiers du coffre. Si plusieurs entrées partagent le même nom dans différents dossiers, 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 d'API. Si plusieurs entrées d'identifiants correspondent, une erreur est retournée. Pour les scénarios comportant de nombreuses écritures (opérations PushSecret fréquentes), préférez les références par UUID afin d'éviter la recherche supplémentaire à chaque opération.

Vous pouvez trouver les UUID dans l'interface Web de Devolutions Server en consultant 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'identifiant	Type d'entrée Devolutions Server	Propriétés disponibles
Par défaut	Identifiant	username, password, domain
Code d'accès	Secret	password
Clé d'API	Identifiant	api-id, api-key, tenant-id
Principal de service Azure	Identifiant	client-id, client-secret, tenant-id
Chaîne de connexion	Identifiant	connection-string
Clé privée	Identifiant	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 « Secret » apparaissent comme un type d'entrée distinct et sont associées en interne au sous-type d'identifiant Code d'accès.

Exemples

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

Pour récupérer des propriétés spécifiques à partir 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

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

Pousser les secrets

Le fournisseur Devolutions Server prend en charge l'envoi 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'

Note : Push secret met à jour le champ de 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 prise en charge pour le moment.

• Certificats d'AC 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 certificat : Les types d'entrée de certificat (Document/Certificate) ne sont pas pris en charge pour le moment. Seules les entrées d'identifiants sont prises en charge.

Dépannage

Erreurs d'authentification

Si vous recevez des erreurs d'authentification :

1. Vérifiez que l'ID d'application et le secret sont corrects.

2. Assurez-vous que l'application possède les permissions nécessaires dans Devolutions Server.

3. Vérifiez que l'URL du serveur Devolutions Server est accessible depuis votre grappe Kubernetes.

Entrée introuvable

Si une entrée est introuvable :

1. Vérifiez que les références du coffre et de l'entrée sont correctes (UUID ou nom)

2. Assurez-vous que l'application possède au moins un accès en lecture au coffre

3. Vérifiez que l'entrée existe et qu'il s'agit d'une entrée de type Identifiant ou Secret

4. Assurez-vous que l'application possède au moins les permissions 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 » lorsque vous utilisez des références par nom, cela signifie que plus d'une entrée d'identifiants porte le même nom dans le coffre. Utilisez l'UUID de l'entrée au lieu du nom pour cibler la bonne entrée.