Crossplane : éviter les pièges et les suppressions accidentelles

Crossplane permet de provisionner et gérer des ressources cloud directement depuis Kubernetes, via des fichiers YAML intégrés dans vos workflows GitOps. Mais ce pouvoir s'accompagne d'un risque réel : un kubectl delete mal placé, un merge sur la mauvaise branche, une mise à jour de provider non contrôlée, et une base de données de production disparaît.

Cet article couvre trois points de configuration critiques pour un déploiement Crossplane en production : le versionnage des providers, la deletionPolicy, et les managementPolicies.

Une architecture en deux couches

L'infrastructure cloud se divise naturellement en deux couches avec des cycles de vie distincts :

Couche fondation (infrastructure de base) : cluster Kubernetes, réseau VPC, comptes de service IAM de base. Gérée par les équipes plateforme avec des outils IaC traditionnels (Terraform, Pulumi, OpenTofu).

Couche applicative (ressources des équipes) : buckets GCS, instances Cloud SQL, Redis, Artifact Registry, routes Gateway API. Gérée par les équipes de développement via des Claims Crossplane.

Les outils IaC traditionnels brillent pour l'infrastructure stable et partagée ; Crossplane excelle pour les nombreuses ressources applicatives liées aux workflows des équipes.

Versionnage des providers : ne laissez pas Crossplane se mettre à jour tout seul

Les providers sont des ressources Kubernetes déclaratives. Sans version épinglée, Crossplane se met automatiquement à jour vers la dernière version : une pratique dangereuse.

Configuration risquée

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-gcp-sql
spec:
  package: xpkg.upbound.io/upbound/provider-gcp-sql:v1

Configuration recommandée

apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
  name: provider-gcp-sql
spec:
  package: xpkg.upbound.io/upbound/provider-gcp-sql:v1.8.0

Risque concret : CRD bloquée en état Terminating

Une mise à jour non contrôlée peut introduire des changements cassants dans les CRDs. Quand Crossplane tente de supprimer d'anciennes CRDs pour installer de nouvelles versions, elles se bloquent à l'état Terminating si des Managed Resources dépendantes existent. Une suppression en cascade peut alors affecter des ressources d'authentification critiques.

Épinglez toujours une version patch explicite pour vos providers. Mettez-les à jour manuellement, de façon contrôlée, en testant d'abord sur un environnement non critique.

deletionPolicy : le paramètre qui peut supprimer votre base de production

deletionPolicy détermine ce qui arrive aux ressources cloud quand les ressources Crossplane sont supprimées.

Delete (défaut) : la ressource cloud est supprimée avec la ressource Crossplane
Orphan : la ressource cloud est conservée ; Crossplane cesse de la gérer

Scénarios risqués

helm uninstall d'une chart applicative qui embarque des Claims Crossplane
kubectl delete namespace accidentel
Suppressions GitOps sur une mauvaise branche

Recommandation : Orphan par défaut

Définissez deletionPolicy: Orphan comme défaut dans la Composition, tout en le rendant configurable via les paramètres du Claim pour les suppressions intentionnelles.

Exemple d'implémentation

Managed Resource :

apiVersion: sql.gcp.upbound.io/v1beta1
kind: DatabaseInstance
metadata:
  name: my-postgres
spec:
  deletionPolicy: Orphan
  forProvider:
    databaseVersion: POSTGRES_15
    region: europe-west1
    settings:
      - tier: db-f1-micro

Patch dans la Composition :

patches:
  - type: FromCompositeFieldPath
    fromFieldPath: spec.parameters.deletionPolicy
    toFieldPath: spec.deletionPolicy

Paramètre dans l'XRD :

spec:
  parameters:
    deletionPolicy:
      type: string
      enum: [Delete, Orphan]
      default: Orphan

Claim développeur (minimal, sécurisé par défaut) :

apiVersion: platform.example.com/v1alpha1
kind: PostgresInstance
metadata:
  name: my-app-db
spec:
  parameters:
    size: small
    region: europe-west1

managementPolicies : définir ce que Crossplane a le droit de faire

managementPolicies contrôle les opérations autorisées sur les ressources cloud. La valeur par défaut ["*"] accorde toutes les permissions : créer, modifier, supprimer et récupérer les valeurs initialisées par le cloud.

Politiques disponibles

Politique	Description
`Observe`	Observer les ressources existantes sans modification
`Create`	Créer de nouvelles ressources
`Update`	Modifier les ressources
`Delete`	Supprimer les ressources
`LateInitialize`	Récupérer les valeurs initialisées par le cloud et les écrire dans le spec
`*`	Toutes les politiques (défaut)

Importer des ressources existantes

Commencez avec Observe uniquement lors de l'import de ressources créées manuellement :

apiVersion: sql.gcp.upbound.io/v1beta1
kind: DatabaseInstance
metadata:
  name: existing-prod-db
  annotations:
    crossplane.io/external-name: my-existing-instance-name
spec:
  managementPolicies:
    - Observe
  forProvider:
    databaseVersion: POSTGRES_15
    region: europe-west1
    settings:
      - tier: db-custom-2-7680

Après avoir confirmé que l'observation réussit (Synced: True, Ready: True), élargissez progressivement les permissions.

LateInitialize et les diffs GitOps

LateInitialize récupère les valeurs par défaut du cloud provider et les écrit dans le spec, ce qui peut provoquer des diffs GitOps constants. Évitez de l'activer pour une gestion standard :

spec:
  managementPolicies:
    - Create
    - Update
    - Delete

Conclusion

Crossplane gère efficacement les ressources cloud de la couche applicative depuis Kubernetes, mais nécessite une configuration réfléchie pour éviter les incidents d'infrastructure.

Les quatre règles à retenir :

Séparez les couches : IaC traditionnel pour l'infrastructure de base, Crossplane pour les ressources applicatives
Épinglez les versions des providers : les mises à jour automatiques risquent de bloquer les CRDs
Utilisez deletionPolicy: Orphan par défaut : rendez-le configurable dans les Compositions
Soyez explicite sur les managementPolicies : commencez par Observe lors des imports, puis élargissez progressivement

Ces quatre règles ne couvrent pas tous les cas, mais elles protègent contre les incidents les plus fréquents et les plus douloureux.