Erreur de permission de namespace ArgoCD ExternalSecret

Problème

Les ExternalSecrets définis dans un ApplicationSet partagé « external-secrets-resources » échouent à se déployer vers des namespaces qui ne figurent pas dans les destinations autorisées du projet ArgoCD. La synchronisation montre OutOfSync mais refuse d'appliquer les changements.

Contexte / Conditions déclencheurs

L'application ArgoCD affiche un statut OutOfSync mais ne se synchronise pas

La vérification des ressources de l'application affiche :

message: namespace gorse is not permitted in project 'infrastructure'

L'ExternalSecret se trouve dans un ApplicationSet partagé (par exemple, external-secrets-resources)
Le namespace cible appartient à une autre application (par exemple, l'app gorse dans le projet default)
Utilisation du pattern apps-of-apps avec isolation basée sur les projets

Cause racine

Les projets ArgoCD définissent les namespaces de destination autorisés. Quand les ExternalSecrets sont déployés via un projet « infrastructure » centralisé mais ciblent des namespaces gérés par des projets spécifiques aux applications, le projet infrastructure n'a pas la permission de déployer vers ces namespaces.

Solution

Déplacer l'ExternalSecret du ressource partagée external-secrets-resources vers l'application elle-même.

Étape 1 : Créer l'ExternalSecret dans l'application

# k8s/applications/gorse/base/external-secret.yaml
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: gorse-secrets
  namespace: gorse
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: gcp-secret-manager
    kind: ClusterSecretStore
  target:
    name: gorse-secrets
    creationPolicy: Owner
  data:
    - secretKey: api_key
      remoteRef:
        key: gorse-api-key-ENVIRONMENT

Étape 2 : Ajouter à la kustomization de l'application

# k8s/applications/gorse/base/kustomization.yaml
resources:
  - namespace.yaml
  - external-secret.yaml  # Ajouter ici
  - deployment.yaml

Étape 3 : Ajouter des patches spécifiques à l'environnement dans les overlays

# k8s/applications/gorse/overlays/staging/kustomization.yaml
patches:
  - target:
      kind: ExternalSecret
      name: gorse-secrets
    patch: |-
      - op: replace
        path: /spec/data/0/remoteRef/key
        value: gorse-api-key-staging

Étape 4 : Supprimer de external-secrets-resources

Supprimer l'ExternalSecret de k8s/external-secrets/base/ et tous les patches d'overlay.

Vérification

Synchroniser l'application : argocd app sync gorse
Vérifier le statut de l'ExternalSecret : kubectl get externalsecrets -n gorse
Vérifier que le secret a été créé : kubectl get secrets -n gorse

Solutions alternatives

Option 1 : Étendre les destinations du projet

Ajouter le namespace aux destinations autorisées du projet infrastructure dans ArgoCD. Non recommandé car cela rompt l'isolation des projets.

Option 2 : Utiliser ClusterSecretStore

Si vous utilisez ClusterSecretStore, le secret peut être référencé depuis n'importe quel namespace. L'ExternalSecret lui-même doit toujours se trouver dans un namespace autorisé.

Remarques

Ce pattern est courant lors de la migration de configurations ArgoCD monolithiques à modulaires
Chaque application doit posséder ses définitions de secrets pour une meilleure isolation
ClusterSecretStore reste partagé ; seul l'ExternalSecret se déplace
Le projet « infrastructure » gère généralement les ressources au niveau du cluster, pas les secrets spécifiques aux applications

argocd-externalsecret-namespace-permission