Aller au contenu principal

Multi-tenancy

Table des matières​

  1. Concept
  2. Isolation par namespace
  3. Isolation par repository
  4. RBAC et ServiceAccounts
  5. Patterns avancés
  6. Exercices pratiques

1 - Concept​

Qu'est-ce que le Multi-tenancy ?​

Le multi-tenancy permet de partager un cluster Flux entre plusieurs équipes avec isolation.

Modèles de multi-tenancy​

ModèleDescriptionIsolation
NamespaceÉquipes dans des namespaces séparésMoyenne
RepositoryChaque équipe a son repo GitForte
ClusterClusters séparésMaximale

🔝 Retour à la table des matières​

2 - Isolation par namespace​

Structure​

clusters/production/
├── flux-system/
├── tenants/
│   ├── team-a/
│   │   ├── namespace.yaml
│   │   ├── rbac.yaml
│   │   └── kustomization.yaml
│   └── team-b/
│       ├── namespace.yaml
│       ├── rbac.yaml
│       └── kustomization.yaml
└── infrastructure/

Namespace pour un tenant​

# tenants/team-a/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: team-a
  labels:
    toolkit.fluxcd.io/tenant: team-a

Kustomization limitée au namespace​

# tenants/team-a/kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: team-a-apps
  namespace: team-a
spec:
  interval: 5m
  path: ./apps
  sourceRef:
    kind: GitRepository
    name: team-a-repo
    namespace: team-a
  prune: true
  targetNamespace: team-a  # Force le namespace
  serviceAccountName: team-a-flux  # ServiceAccount limité

Restreindre les namespaces cibles​

spec:
  targetNamespace: team-a
  # OU
  patches:
    - patch: |
        - op: replace
          path: /metadata/namespace
          value: team-a
      target:
        kind: '*'

🔝 Retour à la table des matières​

3 - Isolation par repository​

Structure recommandée​

# Repo platform-admin (admin seulement)
platform-gitops/
├── clusters/
│   └── production/
│       ├── flux-system/
│       └── tenants/
│           ├── team-a.yaml  # GitRepository + Kustomization
│           └── team-b.yaml

# Repo team-a (équipe A seulement)
team-a-gitops/
├── apps/
│   ├── frontend/
│   └── backend/
└── kustomization.yaml

# Repo team-b (équipe B seulement)
team-b-gitops/
├── apps/
│   └── api/
└── kustomization.yaml

Référencer le repo de l'équipe​

# platform-gitops/clusters/production/tenants/team-a.yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: team-a-repo
  namespace: team-a
spec:
  interval: 1m
  url: https://github.com/org/team-a-gitops
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: team-a
  namespace: team-a
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: team-a-repo
  path: ./apps
  prune: true
  serviceAccountName: team-a-flux

🔝 Retour à la table des matières​

4 - RBAC et ServiceAccounts​

ServiceAccount pour un tenant​

apiVersion: v1
kind: ServiceAccount
metadata:
  name: team-a-flux
  namespace: team-a

Role limité​

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-a-flux
  namespace: team-a
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

RoleBinding​

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-flux
  namespace: team-a
subjects:
  - kind: ServiceAccount
    name: team-a-flux
    namespace: team-a
roleRef:
  kind: Role
  name: team-a-flux
  apiGroup: rbac.authorization.k8s.io

Limiter les ressources créables​

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-a-flux
  namespace: team-a
rules:
  # Autoriser Deployments, Services, ConfigMaps
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets"]
    verbs: ["*"]
  - apiGroups: [""]
    resources: ["services", "configmaps", "secrets"]
    verbs: ["*"]
  # Interdire les Ingress (exemple)
  # - apiGroups: ["networking.k8s.io"]
  #   resources: ["ingresses"]
  #   verbs: ["*"]

🔝 Retour à la table des matières​

5 - Patterns avancés​

App-of-apps pattern​

# tenants/kustomization.yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: tenants
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: flux-system
  path: ./tenants
  prune: true

Network Policies​

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-same-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector: {}

Resource Quotas​

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-a-quota
  namespace: team-a
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"

Limit Ranges​

apiVersion: v1
kind: LimitRange
metadata:
  name: team-a-limits
  namespace: team-a
spec:
  limits:
    - default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      type: Container

🔝 Retour à la table des matières​

6 - Exercices pratiques​

Exercice 1 : Créer un tenant​

# team-demo-tenant.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: team-demo
  labels:
    toolkit.fluxcd.io/tenant: team-demo
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: team-demo-flux
  namespace: team-demo
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: team-demo-flux
  namespace: team-demo
rules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-demo-flux
  namespace: team-demo
subjects:
  - kind: ServiceAccount
    name: team-demo-flux
    namespace: team-demo
roleRef:
  kind: Role
  name: team-demo-flux
  apiGroup: rbac.authorization.k8s.io

Quiz​

Q1. Pourquoi utiliser un ServiceAccount par tenant ?

Réponse

Pour limiter les permissions du Kustomize Controller au namespace du tenant uniquement. Sans ServiceAccount dédié, Flux utilise ses propres permissions (cluster-admin) et peut déployer partout.

Q2. Quelle est la meilleure isolation : namespace ou repository ?

Réponse

L'isolation par repository est plus forte car :

  • Chaque équipe ne voit que son repo Git
  • Pas d'accès aux secrets des autres
  • Séparation claire des responsabilités

Le namespace seul isole dans le cluster mais pas dans Git.

🔝 Retour à la table des matières​

Points clés à retenir​

  • Multi-tenancy = partage du cluster entre équipes
  • Isolation par namespace, repository, ou cluster
  • ServiceAccount dédié par tenant
  • RBAC pour limiter les permissions
  • NetworkPolicies et ResourceQuotas pour l'isolation

← Chapitre précédent | Chapitre suivant : Bonnes pratiques →