ArgoCD ressources CRDs AppProject, droits, sync windows et repositories (Git, Helm)

ArgoCD CRDs

• Repositories (Git, Helm)
• AppProject
  
  • Ajout des droits
  • Ajout des sync windows

---

 

Repositories (Git, Helm)

Les repositories constituent les sources de vérité pour ArgoCD. Ils contiennent les manifestes Kubernetes que vous souhaitez déployer.

• • Repository Git

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: git@github.com:organisation/private-repo.git
  sshPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
    ...
    -----END OPENSSH PRIVATE KEY-----

 

Pour les repositories HTTPS avec authentification :

apiVersion: v1
kind: Secret
metadata:
  name: https-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: https://github.com/organisation/private-repo.git
  username: git-user
  password: git-password

 

• • Repository Helm

apiVersion: v1
kind: Secret
metadata:
  name: helm-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: helm
  name: stable
  url: https://charts.helm.sh/stable
  username: helm-user  # Optionnel
  password: helm-pass  # Optionnel
  tlsClientCertData: |  # Optionnel
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  tlsClientCertKey: |  # Optionnel
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----

 

• ArgoCD prend en charge plusieurs fonctionnalités avancées pour les repositories :
  • Vérification de certificats TLS personnalisés
  • Authentification par clé SSH ou par nom d'utilisateur/mot de passe
  • Intégration avec des solutions de gestion de secrets comme Vault
  • Suivi de branches, tags ou commits spécifiques

Project

Les AppProject dans ArgoCD sont des groupes logiques qui permettent d'isoler des applications (argo apps) et de définir des politiques spécifiques. Ils constituent un mécanisme crucial pour l'organisatoin, la gouvernance et la sécurité.

Un AppProject ArgoCD typique ressemble à ceci :

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: financial-apps
  namespace: argocd
spec:
  description: "Applications financières critiques"
  
  # Sources de configurations autorisées
  sourceRepos:
  - "git@github.com:organisation/financial-apps.git"
  - "https://helm.example.com/financial-charts"
  
  # Clusters destination autorisés
  destinations:
  - namespace: finance-*
    server: https://kubernetes.prod.example.com
  - namespace: finance-*
    server: https://kubernetes.staging.example.com
    
  # Types de ressources autorisées
  clusterResourceWhitelist:
  - group: ""
    kind: Namespace
  namespaceResourceBlacklist:
  - group: ""
    kind: Secret

 

• Ajout des droits

La gestion précise des droits au sein d'un Project est essentielle pour la sécurité :

spec:
  # Autoriser uniquement certains types de ressources
  namespaceResourceWhitelist:
  - group: "apps"
    kind: Deployment
  - group: "apps"
    kind: StatefulSet
  - group: ""
    kind: Service
  - group: "networking.k8s.io"
    kind: Ingress
    
  # Interdire expressément certaines ressources
  namespaceResourceBlacklist:
  - group: ""
    kind: Secret
  - group: ""
    kind: ConfigMap
    
  # Autoriser certaines ressources au niveau cluster
  clusterResourceWhitelist:
  - group: ""
    kind: Namespace
  - group: "storage.k8s.io"
    kind: StorageClass
    
  # Rôles pour accès RBAC
  roles:
  - name: developer
    description: Rôle développeur avec accès limité
    policies:
    - p, proj:financial-apps:developer, applications, get, financial-apps/*, allow
    - p, proj:financial-apps:developer, applications, sync, financial-apps/*, allow
    
  - name: admin
    description: Rôle administrateur avec accès complet
    policies:
    - p, proj:financial-apps:admin, applications, *, financial-apps/*, allow

 

• Les contrôles d'accès peuvent être affinés grâce à :
  • namespaceResourceWhitelist et namespaceResourceBlacklist : Pour contrôler quelles ressources peuvent être déployées dans les namespaces
  • clusterResourceWhitelist et clusterResourceBlacklist : Pour contrôler quelles ressources au niveau cluster peuvent être déployées
  • roles : Pour définir des ensembles de permissions spécifiques aux utilisateurs

 

• Ajout des sync windows

Les sync windows permettent de contrôler quand les synchronisations peuvent se produire, offrant un mécanisme crucial pour les déploiements en production :

spec:
  syncWindows:
  # Fenêtre d'autorisation de synchronisation (maintenance planifiée)
  - kind: allow
    schedule: "0 22 * * 1-5"  # 22h00 du lundi au vendredi
    duration: 2h              # Pendant 2 heures
    applications:
    - "*-prod"                # Pour toutes les applications avec suffixe -prod
    namespaces:
    - production
    
  # Fenêtre de refus de synchronisation (heures de bureau)
  - kind: deny
    schedule: "0 9 * * 1-5"   # 9h00 du lundi au vendredi
    duration: 8h              # Pendant 8 heures
    applications:
    - "financial-*"           # Pour toutes les applications avec préfixe financial-
    namespaces:
    - finance-prod
    clusters:
    - production
    # Autoriser les synchronisations manuelles même pendant la fenêtre deny
    manualSync: true

 

• Les sync windows offrent une grande flexibilité :
  • kind : allow (autorise uniquement pendant la fenêtre) ou deny (refuse pendant la fenêtre)
  • schedule : Format cron standard
  • duration : Durée de la fenêtre
  • Filtres par applications, namespaces et clusters
  • manualSync : Option pour permettre des synchronisations manuelles même pendant les fenêtres deny

 

Exemple de projet argo classic

• Créer le fichier techledger-api.yaml pour les projets au sens argo qui contenir les application argo pour le deploiement des api ecommerce et web server.

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: techledger-api
  namespace: argocd
spec:
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  description: Deploy techledger api for ecommerce
  destinations:
  - name: '*'
    namespace: '*'
    server: '*'
  sourceRepos:
  - '*'

---
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: web-server
  namespace: argocd
spec:
  clusterResourceWhitelist:
  - group: '*'
    kind: '*'
  description: Deploy techledger web-server for ecommerce
  destinations:
  - name: '*'
    namespace: '*'
    server: '*'
  sourceRepos:
  - '*'

 

• Appliquer le ficher

kubectl apply -f techledger-api.yaml

 

 

• Pour supprimer

kubectl delete -f techledger-api.yaml