Dans une approche GitOps, tout passe par le repo Git : les manifests Kubernetes, les configurations, et idéalement les secrets aussi. Mais comment gérer les secrets de manière sécurisée dans un repo Git ?

SOPS : Secrets OPerationS

Principe : chiffrement côté fichier

SOPS s’intègre aux KMS, par exemple sur GCP Cloud Key Management via le principe d’Envelope Encryption : il génère une clé symétrique éphémère (DEK) pour chiffrer les secrets, et délègue à GCP KMS le chiffrement de cette DEK.

Le KMS ne voit jamais les secrets eux-mêmes, et le fichier commité dans Git contient les valeurs chiffrées ainsi que la DEK chiffrée.

En local, un gcloud auth application-default login suffit alors qu’en production sur GKE il est plutot préférable d’utiliser le Workload Identity pour lier le ServiceAccount Kubernetes au compte de service GCP.

Chaque opération est enfin tracée dans Cloud Audit Logs.

Limitations

• Nécessite une infrastructure de gestion de clés externe (KMS ou PGP/Age). Cela introduit une dépendance sur AWS KMS, GCP KMS, etc.
• La rotation de clé implique de re-chiffrer tous les fichiers concernés (sops updatekeys).
• SOPS ne crée pas de Secret Kubernetes directement. Il faut un outil intermédiaire : Helm Secrets, ArgoCD avec plugin, Kustomize + plugin, ou un job de déchiffrement en pipeline CI/CD.
• Le déchiffrement se fait souvent dans le pipeline CI/CD ou sur le poste du développeur. La valeur en clair transite quelque part, ce qui élargit la surface d’attaque.
• Contrairement à Sealed Secrets + un opérateur GitOps, SOPS seul ne met pas à jour les secrets dans le cluster automatiquement.

C’est l’outil que j’ai le plus utilisé dans un contexte professionnel, je trouve que c’est un bon compromis pour gérer les secrets en GitOps à condition d’accepter la complexité de gestion des clés et de mettre en place les bonnes pratiques pour éviter les erreurs humaines (ex: commit de secrets en clair) qui spoiler finiront par arriver

SOPS + ArgoCD

Sops s’intègre très bien avec ArgoCD via le plugin argocd-vault-plugin.

Sinon il est aussi possible d’installer Helm Secrets comme Config Management Plugin.

Exemple d’utilisation

# Chiffrer un fichier de secrets
sops -e secrets.yaml > secrets.enc.yaml
# Déchiffrer un fichier de secrets
sops -d secrets.enc.yaml > secrets.yaml
# Mettre à jour les clés de chiffrement
sops updatekeys secrets.enc.yaml
# Editer un fichier de secrets chiffré
sops edit secrets.enc.yaml

Les alternatives et leurs limites

Sealed Secrets : côté cluster, clé non portable

Les Sealed Secrets(GitHub) de Bitnami permettent de chiffrer les secrets côté cluster.

Sealed Secrets est composé en 2 parties:

• Un controlleur côté cluster (installable via Helm)
• Une CLI côté client : kubeseal (brew install kubeseal)

kubeseal utilise une clé asymétrique pour chiffrer les secrets que seul le contrôleur peut déchiffrer. Ces secrets chiffrés sont ensuite encodés dans une ressource SealedSecret.

Limitations

Voici selon moi les principales limitations de Sealed Secrets :

• La clé de chiffrement est stockée dans le cluster, ce qui rend les secrets non portables entre clusters.
• En cas de compromission du cluster, les secrets peuvent être à risque.
• En cas de disaster recovery, la restauration du cluster doit inclure la restauration de la clé de chiffrement pour pouvoir accéder aux secrets.
• Les secrets sont uniquement utilisable dans un contexte Kubernetes, pas de possibilité de les utiliser pour d’autres usages (CI/CD, etc).

Je n’ai pas eu l’occasion d’utiliser Sealed Secrets dans un milieu professionnel, mais j’ai pu l’expérimenter dans des projets personnels.

Vault : puissant mais lourd à opérer

Hashicorp Vault est un serveur centralisé de gestion de secrets. Ils sont stockés, chiffrés et distribués dynamiquement via une API et les applications les récupèrent au runtime.

Limitations

• Complexité opérationnelle élevée : Vault est un service à part entière qu’il faut déployer, configurer, superviser et maintenir.
• Single point of failure potentiel : Si Vault est down, toutes les applications qui récupèrent leurs secrets dynamiquement peuvent être impactées.
• C’est un outil (trop) complet : Les concepts sont nombreux et nécessitent un temps de montée en compétence réel avant d’opérer Vault sereinement.

C’est un outil que j’ai eu l’occasion d’utiliser mais je n’ai jamais eu la “chance” de le déployer et l’opérer moi même de A à Z, je ne me sens pas légitime pour en parler plus en détail dans cet article.

A Retenir

SOPS est un outil de chiffrement de secrets qui peut s’intégrer dans une approche GitOps. Comme tout outil, il vient avec ses avantages et ses inconvénients, il est important de les connaître pour faire un choix éclairé en fonction de son contexte et de ses besoins.

Pour résumer très grossièrement préférez Sealed Secrets pour démarrer et les cas d’usage simples, SOPS pour les cas d’usage plus complexes et les équipes qui ont déjà une bonne maîtrise de la gestion de clés, et Vault pour les besoins les plus avancés et les équipes qui ont les ressources pour l’opérer sereinement.

Sources

• SOPS GitHub
• Blog de Stéphane Robert - Sealed Secrets
• Vault Documentation
• ArgoCD Vault Plugin

CMCTL est un outil en ligne de commande pour interagir avec Cert Manager. CMCTL permet de gérer les ressources Cert Manager, de diagnostiquer les problèmes et d’automatiser certaines tâches liées à la gestion des certificats. Puisque nous l’avons installé dans le précédent article il me parassait intéressant de partager mes commandes préférées pour interagir avec Cert Manager via cmctl.

Installation

brew install cert-manager/cert-manager/cmctl

Sinon pour Windows via scoop

scoop install main/cmctl

Utilisation

Commandes préférées

Afficher les certificats gérés par Cert Manager :

kubectl get certificates -A

Afficher les certificate requests en cours :

kubectl get certificaterequest -A

Renouveler un certificat manuellement :

cmctl renew  <nom-du-certificat>

Approuver/Désapprouver une demande de certificat manuellement :

$ cmctl approve -n istio-system mesh-ca --reason "pki-team" --message "this certificate is valid"
Approved CertificateRequest 'istio-system/mesh-ca'
$ cmctl deny -n my-app my-app --reason "example.com" --message "violates policy"
Denied CertificateRequest 'my-app/my-app'

Inspecter un certificat en détail :

cmctl inspect <nom-du-certificat>

Conclusion

C’est un article volontairement cours pour partager cet outil et les commandes que j’utilise le plus souvent pour manipuler les ressources de Cert Manager.

Sources

• https://cert-manager.io/docs/reference/cmctl/

Nous allons installer Nginx Gateway Fabric pour exposer nos services Kubernetes sur internet, ainsi que Cert Manager pour gérer les certificats TLS.

Architecture cible

Je possède un nom de domaine chez Cloudflare, je vais donc utiliser Cloudflare comme DNS provider pour gérer les enregistrements DNS de mon domaine. Nginx Gateway Fabric sera configuré pour utiliser un LoadBalancer de type External, ce qui me permettra d’obtenir une adresse IP publique pour exposer mes services.

Voici un schéma pour une meilleur compréhension :

  graph TD
    A[Internet] --> B[Cloudflare DNS + Proxy]
    B --> C[Enregistrement DNS pointant vers l'IP du LoadBalancer GCP]
    C --> D[LoadBalancer GCP]
    D --> E[Nginx Gateway Fabric sur Kubernetes]
    E --> F[HTTPRoute -> Services Kubernetes]
    F --> G[Cert Manager pour TLS]

Étapes

1. Installation de la CRD gateway API

Les ingress controller ne sont plus supportés, il faut désormais ce tourner vers les gateway API. Il existe plusieurs implémentations, j’ai choisi d’installer Nginx Gateway Fabric qui est une solution robuste et bien supportée.

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.4.0/standard-install.yaml

ou via ArgoCD (la sync-wave à 0 permet de s’assurer que les CRDs sont installées avant les autres ressources) :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: gateway-api-crds
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  project: default
  source:
    repoURL: https://github.com/nginx/nginx-gateway-fabric.git
    targetRevision: v2.6.3
    path: config/crd/gateway-api/standard
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - ServerSideApply=true

2. Installation de Nginx Gateway Fabric

Je vais aller assez vite sur l’installation de Nginx Gateway Fabric, si vous avez suivi les articles précédents cela ne devrait pas poser de problème.

On ajoute dans notre repo de CD la configuration suivante :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: nginx-gateway-fabric
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  annotations:
    argocd.argoproj.io/sync-wave: "1"
spec:
  project: default
  source:
    repoURL: ghcr.io/nginx/charts
    chart: nginx-gateway-fabric
    targetRevision: 2.6.3
    helm:
      releaseName: nginx-gateway-fabric
  destination:
    server: https://kubernetes.default.svc
    namespace: nginx-gateway
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

Après quelques secondes les ressources sont créées et nous avons notre gateway qui tourne.

kubectl get pods -n nginx-gateway
NAME                                    READY   STATUS    RESTARTS   AGE
nginx-gateway-fabric-77c559bb4f-c7zlb   1/1     Running   0          93s

3. Installation de Cert Manager

Le principe est le même, voici la configuration à appliquer :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: cert-manager
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  annotations:
    argocd.argoproj.io/sync-wave: "0"
spec:
  project: default
  source:
    repoURL: https://charts.jetstack.io
    chart: cert-manager
    targetRevision: v1.20.2
    helm:
      releaseName: cert-manager
      values: |
        crds:
          enabled: true
          keep: true
  destination:
    server: https://kubernetes.default.svc
    namespace: cert-manager
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Après quelques secondes les ressources sont créées et nous avons notre cert manager qui tourne.

kubectl get pods -n cert-manager
NAME                                       READY   STATUS              RESTARTS   AGE
cert-manager-65dd558d9c-qzjw9              1/1     Running             0          5m6s
cert-manager-cainjector-77bd875bf4-6bcpn   1/1     Running             0          5m5s
cert-manager-startupapicheck-fhsng         0/1     ContainerCreating   0          2m29s
cert-manager-webhook-69666f4d4c-7wccg      1/1     Running             0          5m6s

4. Configuration Cloudflare

Récupération de l’IP du LoadBalancer GCP

Maintenant que ma gateway est en place, je vais configurer Cloudflare pour pointer mon domaine vers l’IP publique de mon LoadBalancer GCP. Je vais créer un enregistrement A dans Cloudflare qui pointe vers l’IP du LoadBalancer, et je vais activer le proxy de Cloudflare pour bénéficier de la protection DDoS et du CDN.

Pour cela il faut récupérer l’IP du LoadBalancer GCP qui a été créé pour exposer Nginx Gateway Fabric. Vous pouvez le faire avec la commande suivante :

kubectl get svc -n nginx-gateway
# Noter l'EXTERNAL-IP → à mettre dans Cloudflare DNS (enregistrement A)

Création d’un token API Cloudflare

Pour automatiser la configuration de Cloudflare, je vais créer un token API avec les permissions nécessaires pour gérer les enregistrements DNS. Dans Cloudflare → My Profile → API Tokens → Create Token :

Template : Edit zone DNS Permissions : Zone / DNS / Edit Zone : mon domaine (ici valerian-pyckaert.dev)

kubectl create secret generic cloudflare-api-token \
  --namespace cert-manager \
  --from-literal=api-token=<TOKEN_CF>

5. Configuration de Cert Manager pour Cloudflare

Il s’agit maintenant d’ajouter une ressource ClusterIssuer pour utiliser le token API Cloudflare et gérer les certificats TLS automatiquement.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    email: ton@email.com
    server: https://acme-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: letsencrypt-key
    solvers:
    - dns01:
        cloudflare:
          apiTokenSecretRef:
            name: cloudflare-api-token
            key: api-token

Une fois cette configuration appliquée, Cert Manager pourra automatiquement obtenir et renouveler les certificats TLS pour les domaines gérés via Cloudflare. Pour vérifier le bon fonctionnement :

kubectl get clusterissuer -A
NAME               READY   AGE
letsencrypt-prod   True    17h
kubectl get certificate -A
default     wildcard-cert   True    wildcard-cert   54m

6. Configuration d’une HTTPRoute pour exposer un service

Maintenant que tout est en place, nous allons créer une ressource HTTPRoute pour exposer un service Kubernetes via Nginx Gateway Fabric et positionner le certificat généré par Cert Manager.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: main-gateway
  namespace: default
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  gatewayClassName: nginx
  listeners:
  - name: https
    hostname: "*.mondomaine.com"
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - name: wildcard-cert
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app
spec:
  parentRefs:
  - name: main-gateway
  hostnames:
  - "app.mondomaine.com"
  rules:
  - backendRefs:
    - name: my-service
      port: 80
---

Résultat

Si vous avez suivi chaque étapes vous devriez avoir un résultat similaire à celui-ci :

❯ kubectl get gateway -A
NAMESPACE   NAME           CLASS   ADDRESS         PROGRAMMED   AGE
default     main-gateway   nginx   34.156.85.195   True         29m
❯ kubectl get httproute -A
NAMESPACE   NAME        HOSTNAMES                         AGE
default     nginx-app   ["nginx.valerian-pyckaert.dev"]   29m
❯ kubectl get certificate -A
NAMESPACE   NAME            READY   SECRET          AGE
default     wildcard-cert   True    wildcard-cert   21m

Votre service devrait être accessible via l’URL https://nginx.mondomaine.com et le certificat TLS devrait être valide, en l’occurence pour moi c’était https://nginx.valerian-pyckaert.dev avec un certificat pour valerian-pyckaert.dev généré par Let’s Encrypt.

Pour ce faire j’ai enregistré un enregistrement A dans Cloudflare qui pointe vers l’IP du LoadBalancer GCP :

Obstacles rencontrés

La gateway ne peut pas accéder au namespace demo et au service nginx

J’avais installé ma ressource HTTPRoute dans le namespace default alors que mon service nginx était dans le namespace demo. Par défaut, la gateway n’a pas accès aux ressources d’autres namespaces, il faut donc lui accorder les permissions nécessaires.

Soit via un ReferenceGrant :

apiVersion: gateway.networking.k8s.io/v1beta1
kind: ReferenceGrant
metadata:
  name: allow-gateway-to-demo
  namespace: demo
spec:
  from:
  - group: gateway.networking.k8s.io
    kind: HTTPRoute
    namespace: default
  to:
  - group: ""
    kind: Service

Soit installé la ressource HTTPRoute dans le même namespace que le service nginx (ici demo).

Pods en pending

Par péché de rapidité j’ai volontairement omis de spécifier les ressources CPU et memory de mes workloads, ce qui a pour conséquence que les pods sont restés en pending car le scheduler ne pouvait pas les placer sur un nœud. Il faut donc veiller à toujours spécifier les ressources de vos workloads pour éviter ce genre de problème.

Pour la suite

Dans le prochain et dernier article de cette série The Forge je vous parlerai de SOPS et de comment gérer vos secrets de manière sécurisée dans Kubernetes. Nous verrons comment chiffrer vos secrets avec SOPS et les stocker dans Git pour une gestion centralisée et sécurisée de vos secrets.

Pré-requis

• Un cluster GKE up and running
• Connaissance de base de Kubernetes et GitOps
• ArgoCD installé et configuré

Étapes

1. Qu’est ce qu’on va installer ?

1. Installation de la kube-prometheus-stack (Prometheus + Grafana + Alertmanager)

Si vous avez suivi l’article précédent, rien de plus simple : il suffit d’ajouter une nouvelle application dans apps/ dans notre repo de CD.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: kube-prometheus-stack
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    chart: kube-prometheus-stack
    targetRevision: 86.0.1
    helm:
      releaseName: kube-prometheus-stack
      valueFiles: []
      values: |
        grafana:
          enabled: true
          adminPassword: admin
          service:
            type: ClusterIP
        prometheus:
          prometheusSpec:
            retention: 7d
            resources:
              requests:
                cpu: 200m
                memory: 512Mi
              limits:
                memory: 2Gi
            storageSpec: {}
        alertmanager:
          enabled: true
        kubeStateMetrics:
          enabled: true
        nodeExporter:
          enabled: true
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

On push ce fichier kube-prometheus-stack.yaml et Argo se charge de déployer la stack de monitoring dans notre cluster.

Après quelques minutes d’attente, vous devriez voir les pods de Prometheus, Grafana et Alertmanager en cours d’exécution dans le namespace monitoring :

kubectl get pods -n monitoring
NAME                                                        READY   STATUS    RESTARTS   AGE
alertmanager-kube-prometheus-stack-alertmanager-0           2/2     Running   0          2m30s
kube-prometheus-stack-admission-create-ljf79                0/1     Pending   0          41s
kube-prometheus-stack-grafana-6ddb85bf55-j5shg              3/3     Running   0          2m35s
kube-prometheus-stack-kube-state-metrics-5fc57bf8f9-vhfhq   1/1     Running   0          2m35s
kube-prometheus-stack-operator-585c4957f7-2r772             1/1     Running   0          2m35s
prometheus-kube-prometheus-stack-prometheus-0               2/2     Running   0          2m30s
---

Grafana est désormais accessible via un port-forwarding :

kubectl port-forward -n monitoring svc/kube-prometheus-stack-grafana 3000:80

Rendez-vous sur http://localhost:3000 et connectez-vous avec les identifiants admin/admin.

Cliquez ensuite sur “Dashboards” pour voir la liste des dashboards disponibles par défaut avec la chart :

3. Collecte des Logs avec Loki

Là encore il suffit de créer une nouvelle application ArgoCD qui pointe vers le chart Helm de Loki pour déployer un stack de collecte de logs dans notre cluster.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: loki
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://grafana.github.io/helm-charts
    chart: loki
    targetRevision: 7.0.0
    helm:
      releaseName: loki
      values: |
        deploymentMode: SingleBinary
        loki:
          auth_enabled: false
          commonConfig:
            replication_factor: 1
          storage:
            type: filesystem
          schemaConfig:
            configs:
              - from: "2024-01-01"
                store: tsdb
                object_store: filesystem
                schema: v13
                index:
                  prefix: index_
                  period: 24h
        singleBinary:
          replicas: 1
          persistence:
            size: 10Gi
        read:
          replicas: 0
        write:
          replicas: 0
        backend:
          replicas: 0
        gateway:
          enabled: true
        chunksCache:
          enabled: false
        resultsCache:
          enabled: false
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true
      - ServerSideApply=true

Enfin il faut indiquer à Grafana où trouver Loki pour pouvoir visualiser les logs dans notre dashboard.

Pour cela, on ajoute une datasource Loki dans Grafana en utilisant un ConfigMap Kubernetes :

spec:
  source:
    helm:
      values: |
        grafana:
          additionalDataSources:
            - name: Loki
              type: loki
              access: proxy
              url: http://loki-gateway.monitoring.svc.cluster.local
              jsonData:
                maxLines: 1000

Et voilà le résultat :

4. Collecte des logs de notre application

Pour l’heure, les logs de notre application nginx ne sont pas collectés par Loki. Nous allons déployer Alloy en tant que DaemonSet dans notre cluster pour collecter les logs de tous les pods et les envoyer à Loki, il s’agit ici encore d’ajouter une nouvelle application ArgoCD dans notre repo de CD :

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: alloy
  namespace: argocd
  finalizers:
    - resources-finalizer.argocd.argoproj.io
spec:
  project: default
  source:
    repoURL: https://grafana.github.io/helm-charts
    chart: alloy
    targetRevision: 1.16.1
    helm:
      releaseName: alloy
      values: |
        alloy:
          configMap:
            content: |
              discovery.kubernetes "pods" {
                role = "pod"
              }

              discovery.relabel "pods" {
                targets = discovery.kubernetes.pods.targets

                rule {
                  source_labels = ["__meta_kubernetes_namespace"]
                  target_label  = "namespace"
                }
                rule {
                  source_labels = ["__meta_kubernetes_pod_name"]
                  target_label  = "pod"
                }
                rule {
                  source_labels = ["__meta_kubernetes_pod_container_name"]
                  target_label  = "container"
                }
                rule {
                  source_labels = ["__meta_kubernetes_pod_label_app"]
                  target_label  = "app"
                }
              }

              loki.source.kubernetes "pods" {
                targets    = discovery.relabel.pods.output
                forward_to = [loki.write.default.receiver]
              }

              loki.write "default" {
                endpoint {
                  url = "http://loki-gateway.monitoring.svc.cluster.local/loki/api/v1/push"
                }
              }
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

La configuration utilise la syntaxe River d’Alloy pour :

• Découvrir tous les pods Kubernetes
• Extraire les labels namespace, pod, container et app
• Envoyer les logs vers votre Loki gateway
• Alloy sera déployé comme DaemonSet et collectera les logs de votre nginx. Dans Grafana, vous pourrez les consulter avec :

{namespace=“demo”, app=“nginx”}

De retour sur Grafana, la liste des filtres disponibles est désormais bien plus fournie :

Résultat

Dans cet article nous avons vu comment installer une stack de monitoring complète sur Kubernetes avec Prometheus, Grafana et Loki, le tout déployé en GitOps via ArgoCD. Nous avons également vu comment collecter les logs de nos pods sur notre cluster avec Alloy et les visualiser dans Grafana.

Si vous avez suivi toutes les étapes de cet article vous devriez avoir les workloads suivantes :

kubectl get pods -n monitoring
NAME                                                        READY   STATUS    RESTARTS   AGE
alertmanager-kube-prometheus-stack-alertmanager-0           2/2     Running   0          21m
alloy-jb2nf                                                 2/2     Running   0          5m22s
kube-prometheus-stack-grafana-bf74d765f-4hzlt               3/3     Running   0          23m
kube-prometheus-stack-kube-state-metrics-6b747b7c5f-hjjwd   1/1     Running   0          23m
kube-prometheus-stack-operator-59c5d9f8c-q6phj              1/1     Running   0          23m
kube-prometheus-stack-prometheus-node-exporter-zhmfp        1/1     Running   0          23m
loki-0                                                      2/2     Running   0          32m
loki-canary-55ccd5d799-wkc7t                                1/1     Running   0          32m
loki-gateway-6df7c96bc9-l92d2                               1/1     Running   0          32m
prometheus-kube-prometheus-stack-prometheus-0               2/2     Running   0          21m

kubectl get pods -n demo
NAME                     READY   STATUS    RESTARTS   AGE
nginx-7489fb554f-hffjv   1/1     Running   0          33m

L’essentiel des travaux est disponible sur mon repo GitHub

Ce qui vient ensuite

Nous verrons comment exposer notre application à travers la Gateway API dans le prochain article de la série, stay tuned !

Sources :

• kube-prometheus-stack Helm Chart
• Loki Helm Chart
• Alloy Helm Chart

Installation d’ArgoCD pour le déploiement continu sur Kubernetes via Terraform et Helm.

Pré-requis

• Cluster GKE up and running
• Connaissance de base de Kubernetes et GitOps
• Outils : terraform, gcloud, kubectl, helm…

Étapes

1. Installation d’ArgoCD

Pour cette partie j’ai choisi d’installer ArgoCD via Terraform en utilisant le provider Helm. Cela nous permettra de gérer l’installation d’ArgoCD de manière déclarative et reproductible. Argo sera ensuite en charge de déployer les workloads sur notre cluster Kubernetes.

Ajout des providers nécessaires dans notre configuration Terraform :

provider "kubernetes" {
  host                   = "https://${google_container_cluster.primary.endpoint}"
  token                  = data.google_client_config.default.access_token
  cluster_ca_certificate = base64decode(google_container_cluster.primary.master_auth.0.cluster_ca_certificate)
}

provider "helm" {
  kubernetes = {
    host                   = "https://${google_container_cluster.primary.endpoint}"
    token                  = data.google_client_config.default.access_token
    cluster_ca_certificate = base64decode(google_container_cluster.primary.master_auth.0.cluster_ca_certificate)
  }
}

Ne pas oublier terraform init pour installer les providers. Ensuite, nous allons ajouter une ressource Helm pour installer ArgoCD :

resource "helm_release" "argocd" {
  name             = "argocd"
  repository       = "https://argoproj.github.io/argo-helm"
  chart            = "argo-cd"
  version          = "9.5.15"
  namespace        = "argocd"
  create_namespace = true

  set = [
    {
      name  = "dex.enabled"
      value = "false"
    },
    {
      name  = "notifications.enabled"
      value = "false"
    },
    {
      name  = "applicationSet.enabled"
      value = "false"
    },
    {
      name  = "server.extraArgs[0]"
      value = "--insecure"
    }
  ]

  depends_on = [google_container_node_pool.primary_nodes]
}

Ici nous installons ArgoCD dans le namespace argocd en désactivant certaines fonctionnalités que nous n’utiliserons pas pour le moment (Dex, notifications, ApplicationSet) et en configurant le serveur ArgoCD pour qu’il fonctionne en mode non sécurisé (insecure) pour simplifier les choses dans un environnement de développement.

2. Création de la Root Application ArgoCD (App of Apps Pattern)

Le pattern “App of Apps” est une approche recommandée pour organiser les applications dans ArgoCD. Il consiste à créer une application principale (root application) qui référence d’autres applications (child applications).

Cela permet de structurer les déploiements de manière hiérarchique et de faciliter la gestion des dépendances entre les applications.

resource "kubernetes_manifest" "argocd_app" {
  manifest = {
    apiVersion = "argoproj.io/v1alpha1"
    kind       = "Application"
    metadata = {
      name      = "root-app"
      namespace = "argocd"
    }
    spec = {
      project = "default"
      source = {
        repoURL        = "https://github.com/Bernedotcom2312/theforge-cd.git" #Changez pour le votre
        targetRevision = "main"
        path           = "apps"
      }
      destination = {
        server    = "https://kubernetes.default.svc"
        namespace = "default"
      }
      syncPolicy = {
        automated = {
          prune    = true
          selfHeal = true
        }
      }
    }
  }

  depends_on = [helm_release.argocd]
}

Cette configuration crée une application ArgoCD nommée root-app qui pointe vers un dépôt Git contenant les définitions des applications à déployer. Le champ syncPolicy est configuré pour permettre le déploiement automatique et de réparer les ressources qui ne sont pas conformes à la configuration (selfHeal).

3. Application de la configuration Terraform

Maintenant que nous avons ajouté la configuration pour installer ArgoCD et créer la root application, nous pouvons appliquer notre configuration Terraform :

terraform apply

Cette commande va provisionner ArgoCD sur notre cluster GKE et créer la root application qui référencera les applications à déployer depuis notre dépôt Git.

Résultat

ArgoCD est maintenant installé sur notre cluster GKE et prêt à être utilisé pour le déploiement continu de nos applications.

Vous pouvez vérifier que les pods ArgoCD sont en cours d’exécution avec la commande suivante :

kubectl get pods -n argocd
NAME                                                READY   STATUS    RESTARTS      AGE
argocd-application-controller-0                     1/1     Running   0             94s
argocd-applicationset-controller-6c6b88d4bc-krjc5   1/1     Running   0             95s
argocd-dex-server-79fc985b7b-rbz6w                  1/1     Running   2 (77s ago)   96s
argocd-notifications-controller-6c44f9dbbf-v4777    1/1     Running   0             96s
argocd-redis-7979d55d5b-ft6rc                       1/1     Running   0             96s
argocd-repo-server-584c965f87-tzvsg                 1/1     Running   0             95s
argocd-server-5f7d4885d5-vkccj                      1/1     Running   0             95s

Accès au dashboard ArgoCD :

kubectl port-forward svc/argocd-server -n argocd 8080:80

Rendez vous sur http://localhost:8080. Vous devriez avoir un warning de sécurité concernant le mode “insecure” que nous avons configuré pour le serveur ArgoCD, mais c’est acceptable pour un environnement de développement, nous verrons comment sécuriser cela dans une prochaine étape.

Pour se connecter, utilisez les identifiants suivants :

• Username : admin
• Password : le mot de passe est généré automatiquement et stocké dans le secrets argocd-initial-admin-secret dans le namespace argocd. Vous pouvez le récupérer avec la commande suivante :

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d

Notre application d’exemple (Nginx) devrait également être déployée et visible dans l’interface d’ArgoCD.

kubectl get pods -n demo
NAME                    READY   STATUS    RESTARTS   AGE
nginx-78b9f9966-bh7vb   1/1     Running   0          110s

Un dernier port-forward pour accéder à l’application Nginx :

kubectl port-forward svc/nginx -n demo 8081:80

Et voilà le résultat en accèdant au port 8081 de votre localhost :

Ce qui vient ensuite

La prochaine brique de notre plateforme Kubernetes : le monitoring.

Sources

• ArgoCD Documentation
• Terraform Helm Provider
• Blog Stéphane Robert
• Mon Repo Infra
• Mon Repo CD

• Un compte GCP avec les permissions nécessaires pour créer des ressources.
  • API Kubernetes Engine activée
  • Billing account configuré
• Terraform installé sur votre machine
• Quelques connaissances sur Git

Étapes

1. Creation du repository Git

Ici pas question de réinventer la roue, j’utilise un template fournit par Hashicorp(Terraform) pour le bootstrap de mon cluster.

git clone https://github.com/hashicorp-education/learn-terraform-provision-gke-cluster
mv learn-terraform-provision-gke-cluster theforge-infra
cd theforge-infra
git remote set-url origin git@github.com:mon-repo.git      

Nous ferons le tour d’horizon des ressources juste après.

2. Configuration GCLOUD

brew install --cask google-cloud-sdk
gcloud init
gcloud auth application-default login

3. Architecture du repo

4. Fine tuning de la configuration Terraform

Ajout du Project ID et de la région

Quelques modifications à apporter à la configuration de base, notamment le project_id et la region dans le fichier terraform.tfvars :

project_id = "MON_PROJECT_ID"
region     = "europe-west1"

Puis on valide que Terraform est correctement configuré et peut communiquer avec GCP :

terraform init

Terraform has been successfully initialized!

Mise à jour de la version de Terraform et des providers

Le template utilise une version de Terraform et du provider Google qui sont un peu anciennes, il est recommandé de les mettre à jour pour bénéficier des dernières fonctionnalités et corrections de bugs. Dans versions.tf, on peut mettre à jour la version de Terraform et du provider Google :

terraform {
  required_version = ">= 1.15"

  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 7.33.0"
    }
  }
}

Sources :

• Version provider Google
• Version Terraform

Mise à jour de la version de GKE

Par défaut, le template utilise aussi une version de GKE qui n’est plus supportée (1.27.x). Il faut donc mettre à jour la version du cluster dans gke.tf pour une version plus récente, par exemple 1.36.x :

resource "google_container_cluster" "primary" {
  name     = "theforge-cluster"
  location = var.region

  # Autres configurations...

  # Mise à jour de la version du cluster
  min_master_version = "1.36"
}

Ensuite, on peut relancer terraform plan pour vérifier que la configuration est valide avec la nouvelle version.

Sources :

• Versions GKE disponibles

Séparation des ressources dans des fichiers

Pour une meilleure organisation, j’ai choisi de remanier quelque peu la structure du repo en séparant les ressources dans des fichiers dédiés (variables.tf, providers.tf). J’envisage en effet de réutiliser ce repository à l’avenir pour d’autres projets, à ce titre je souhaite le rendre plus modulaire et facilement maintenable.

Résultat

Une fois satisfait de votre configuration il ne reste qu’à lancer la commande terraform apply pour provisionner le cluster sur GCP. Après quelques minutes d’attente, le cluster devrait être opérationnel et vous devriez voir les outputs suivants :

Connexion au cluster

Google Cloud SDK (gcloud) est nécessaire pour récupérer les credentials du cluster et pouvoir interagir avec lui via kubectl.

gcloud container clusters get-credentials "moncluster" --region europe-west1 --project "monprojet"
#> kubeconfig entry generated for moncluster.

Verification du status des pods

Une fois le cluster déployé vous devriez voir les pods du cluster en cours d’exécution :

kubectl get pods -A
NAMESPACE         NAME                                                             READY   STATUS    RESTARTS   AGE
gke-managed-cim   kube-state-metrics-0                                             2/2     Running   0          35m
gmp-system        collector-jc4t8                                                  2/2     Running   0          30m
gmp-system        collector-jdjzw                                                  2/2     Running   0          30m

Repo disponible sur GitHub

L’ensemble de la configuration Terraform utilisée pour ce projet est disponible sur GitHub : theforge-infra.

Erreurs rencontrées

Pas de billing account configuré

ERROR: (gcloud.services.enable) FAILED_PRECONDITION: Billing account for project ‘X’ is not found

Renseignez un billing account valide pour votre projet et c’est réglé.

API Kubernetes désactivée

Error: Error retrieving available container cluster versions: googleapi: Error 403: Kubernetes Engine API has not been used in project deft-accord-496812-k9 before or it is disabled.

Elle était assez explicite : l’API Kubernetes Engine n’était pas activée sur le projet GCP. Je l’ai activée via la console GCP, puis relancé terraform plan pour valider que tout est bon. Vous pouvez aussi l’activer avec la CLI :

gcloud services enable container.googleapis.com

Problème de provisioning du cluster

Google Compute Engine: Not all instances running in IGM after 35m11.660099086s. Expected 1, running 0, transitioning 1. Current errors: [GCE_STOCKOUT]: Instance ‘gke-deft-accord-496812-k-default-pool-19ca1c15-p6ls’ creation failed: The zone ‘projects/deft-accord-496812-k9/zones/europe-west1-c’ does not have enough resources available to fulfill the request. Try a different zone, or try again later.

Résolution : changer la zone de déploiement du cluster dans gke.tfs pour une zone moins sollicitée, par exemple europe-west1-b ou europe-west1-d.

resource "google_container_cluster" "primary" {
  name     = "${var.project_id}-gke"
  location = var.region
  node_locations = ["europe-west1-b", "europe-west1-d"]
  # Autres configurations...
}

Plugin GKE introuvable

couldn’t get current server API group list: Get “https://35.233.30.210/api?timeout=32s”: getting credentials: exec: executable gke-gcloud-auth-plugin.exe not found

Solution : installer le plugin d’authentification GKE pour kubectl, qui est nécessaire pour se connecter au cluster GKE.

gcloud components install gke-gcloud-auth-plugin

Stack : GCP · GKE · Terraform · Helm · ArgoCD · SOPS · Kube-Prom-Stack · Nginx Gateway Fabric · cert-manager

Pourquoi ce projet ?

Je me lance en freelance DevOps / Platform Engineer / Cloud Engineer. Pour montrer ce que je sais faire (et documenter ce que j’apprends en chemin), je démarre un projet fil rouge public : construire une plateforme Kubernetes complète sur GCP, from scratch, avec les outils que j’estime indispensables en 2026.

Chaque article de la série documente une étape, les obstacles rencontrés et comment je les ai résolus. Format court, orienté pratique.

Je vais tenter de garder une approche pragmatique orientée “best practices” (mais pas dogmatique) pour que ce soit utile à d’autres personnes qui veulent se lancer dans la même aventure.

Ce qu’on va construire

Un cluster GKE avec la stack suivante, déployée en GitOps :

Je me focalise sur ce qui me semble essentiel pour adresser la majorité des besoins. A termes j’envisage d’ajouter d’autres composants destinés à des usages plus complexes : KEDA, Karpenter, Dapr, …

Les étapes prévues

1. Création du cluster GKE via Terraform
2. Bootstrap Helm & ArgoCD via Terraform
3. Déploiement de kube-prometheus-stack via ArgoCD
4. Déploiement de Nginx Gateway Fabric / Gateway API via ArgoCD
5. Déploiement de cert-manager + Let’s Encrypt via ArgoCD
6. Mise en place de SOPS pour la gestion des secrets

J’ajouterai probablement d’autres étapes au fur et à mesure* (ex: gestion des node pools, autoscaling, etc.) selon les besoins et les obstacles rencontrés*

Principes de base

• Tout dans Git — aucune modification manuelle sur le cluster après le bootstrap
• Least privilege — les SA GCP auront le minimum requis
• Les secrets ne sont jamais en clair dans le repo
• KISS — Keep It Simple Stupid. Pas de sur-optimisation, pas de microservices inutiles, pas de complexité superflue

Prochaine étape

→ Création du cluster GKE avec Terraform (à venir)

Date de sortie : 22 avril 2026
Nom de code : ハル (Haru — « Printemps » en japonais)

Kubernetes v1.36 est sorti fin avril 2026 sous le nom de code Haru (printemps en japonais), et c’est une release dense.

Voici mon tour d’horizon des changements les plus significatifs.

🔐 Sécurité : des fondations qui arrivent enfin à maturité

User Namespaces : 🟢 Stable

Le problème :

Par défaut, un processus qui tourne en tant que root (UID 0) dans un conteneur est aussi root sur le nœud hôte. En cas de fuite de conteneur (container escape), l’attaquant dispose immédiatement de privilèges root sur la machine, ce qui compromet l’ensemble des workloads du nœud.

La solution :

Les User Namespaces (isolation des UID/GID entre le pod et le nœud) passent en GA (Stable). Kubernetes remape automatiquement les UID/GID du conteneur vers des UID/GID non privilégiés sur le nœud hôte. Un processus root dans le conteneur (UID 0) est vu comme un utilisateur sans privilège sur le nœud (ex : UID 65534).

Exemple :

apiVersion: v1
kind: Pod
metadata:
  name: app-with-userns
  labels:
    app: secure-app
spec:
  hostUsers: false  # Active les User Namespaces
  containers:
  - name: app
    image: myregistry/my-app:latest
    securityContext:
      runAsUser: 0         # root dans le conteneur...
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]
    resources:
      limits:
        memory: "256Mi"
        cpu: "500m"

Avec hostUsers: false, le UID 0 dans le conteneur est remappé vers un UID non privilégié sur le nœud (ex : 65536). Même en cas d’évasion, l’attaquant n’a aucun privilège sur l’hôte.

Fine-Grained Kubelet API Authorization : 🟢 Stable

Le problème :

Kubelet est l’agent qui tourne sur chaque machine de votre cluster et qui s’assure que vos applications fonctionnent. Jusqu’ici, les permissions pour accéder à cet agent étaient soit tout ou rien — un peu comme une serrure unique pour toute une maison.

La solution :

Il est maintenant possible de définir des permissions très précises : cet outil de monitoring peut seulement lire les logs, cet autre outil peut redémarrer des pods mais pas lire les données, etc.

Pourquoi c’est important :

Si un outil tiers est compromis, il ne peut pas profiter de ses accès pour faire n’importe quoi sur vos machines. C’est le principe du moindre privilège appliqué là où ça compte vraiment.

Exemple :

# Exemple de Role pour accéder uniquement aux logs des pods
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-log-reader
rules:
- apiGroups: [""]
  resources: ["pods/log"]
  verbs: ["get", "list"]

Admission Policies immuables : 🔴 Alpha

Le problème :

Un administrateur mal intentionné (ou simplement qui fait une erreur) peut supprimer des règles de sécurité critiques sur un cluster.

La solution :

Certaines politiques de sécurité peuvent maintenant être déclarées comme permanentes dans des fichiers de configuration. Personne ne peut les supprimer via l’API, il faudrait accès direct au cluster pour les retirer.

Exemple :

apiVersion: policy.k8s.io/v1
kind: PodSecurityPolicy
metadata:
  name: no-privileged
spec:
  privileged: false
immutable: true

Declarative Validation : 🟢 Stable

Le problème :

Quand on déploie une application sur Kubernetes, on peut définir des règles pour valider les configurations (ex : “tous les pods doivent avoir un label env”). Historiquement, ces validations passaient par des services externes appelés webhooks, qui rajoutaient de la complexité et pouvaient tomber en panne.

La solution :

Ces règles de validation peuvent maintenant être écrites directement dans la configuration Kubernetes, sans service intermédiaire. Kubernetes les vérifie lui-même, instantanément.

Pourquoi c’est important :

Moins de webhooks à maintenir, moins de latence, et une validation plus robuste au niveau de l’API Server.

⚙️ Gestion des ressources : vers plus de finesse

In-Place Vertical Scaling au niveau Pod : 🟡 Beta

Le problème :

Imaginez une application qui tourne en production et qui commence à manquer de mémoire. Jusqu’ici, la seule solution était de l’arrêter, changer sa configuration, et la redémarrer soit manuellement, soit via le Vertical Pod Autoscaler (VPA).

La solution :

Il est maintenant possible d’augmenter (ou réduire) la mémoire et le CPU alloués à une application en direct, sans interruption. Kubernetes ajuste les ressources à chaud.

J’aime énormément cette feature pour les applications qui ont des besoins variables ou qui sont difficiles à dimensionner à l’avance. C’est un vrai gain de flexibilité et cette feature sera un atout pour réduire encore un peu plus notre facture cloud.

Tiered Memory Protection with Memory QoS : 🟡 Beta

Kubernetes v1.36 affine le modèle d’allocation mémoire : les pods critiques peuvent désormais bénéficier de garanties mémoire plus fortes, tandis que les pods best-effort sont soumis à une pression mémoire plus agressive. Une feature qui change la vie en production sur des nœuds fortement chargés.

Mutable Pod Resources for Suspended Jobs : 🟡 Beta

Le problème :

Kubernetes permet de mettre en pause les ressources de type Job mais si on veut modifier les ressources allouées avant de reprendre le job, ce n’était pas possible.

La solution : Pendant qu’un job est en pause, on peut maintenant modifier ses ressources (plus de mémoire, moins de CPU…) avant de le relancer.

📊 Observabilité et scalabilité de l’API

PSI Metrics : 🟢 Stable

Les métriques PSI (Pressure Stall Information) qui mesurent la pression réelle subie par les workloads sur le CPU, la mémoire et l’I/O passent en GA. Ces métriques Linux sont bien plus précises que les métriques CPU classiques pour détecter une saturation réelle. Si vous utilisez Prometheus, commencez à les intégrer dès maintenant.

# Exemple : pression mémoire sur les nœuds
container_memory_psi_full_total

Cf. PSI Metrics Documentation pour plus de détails.

💾 Stockage

Volume Group Snapshots : 🟢 Stable

Les snapshots groupés de volumes (capturer atomiquement plusieurs PVCs en une seule opération) atteignent la GA. Indispensable pour les bases de données distribuées où la cohérence des snapshots entre plusieurs volumes est critique.

🌐 Réseau : Gateway API v1.5

En parallèle de la release Kubernetes, Gateway API v1.5 est sorti avec plusieurs features passant en stable. Le projet continue de s’imposer comme le successeur d’Ingress, et l’outil Ingress2Gateway 1.0 facilite désormais la migration automatisée de vos ressources Ingress existantes.

Je prévois de faire un article dédié sur Gateway API dans les prochaines semaines, c’est une évolution majeure pour la gestion du trafic dans Kubernetes et il y a beaucoup à dire sur les nouvelles possibilités offertes par cette API.

🗑️ Dépréciations et suppressions à surveiller

Service ExternalIPs

Dépréciés, suppression imminente en v1.37. Si vous utilisez des ExternalIPs pour exposer vos services, il est temps de migrer vers des solutions plus modernes comme les LoadBalancers ou la Gateway API.

Comment vérifier si vous êtes concernés ?

Rien de plus simple avec JQ et kubectl :

kubectl get svc --all-namespaces -o json | jq '.items[] | select(.spec.externalIPs != null) | {namespace: .metadata.namespace, name: .metadata.name, externalIPs: .spec.externalIPs}'

🔄 Ce que ça change pour vos clusters

Conclusion

Kubernetes v1.36 Haru est une release accès sur une gestion plus fine des ressources et sur la sécurité. Plusieurs features clés passent en GA(Stable) et peuvent désormais être utilisées en production.

Le gros point d’attention concerne le décommissionnement à venir des ExternalIPs, qui peut impacter les clusters qui les utilisent pour exposer des services.

Sources : Kubernetes v1.36 Release Notes · Kubernetes Blog, PSI Metrics Documentation, PSI Overview