Confidentialite¶

Classification des données de sécurité runtime¶

Les composants de sécurité runtime manipulent des données qui sont elles-mêmes sensibles :

Donnée	Sensibilite	Risque si expose
Regles Falco	Confidentiel	Un attaquant connait les detections en place et les contourne
Contraintes OPA	Confidentiel	Un attaquant connait les restrictions et trouve des failles
Alertes de sécurité	Confidentiel	Un attaquant sait quelles activités sont détectées
Rapports Trivy	Confidentiel	Un attaquant connait les vulnerabilites presentes
Configuration des seuils	Confidentiel	Un attaquant calibre ses actions sous les seuils
Listes d'exceptions	Confidentiel	Un attaquant exploite les exceptions connues

Les regles révèlent les contrôles

La publication accidentelle des regles Falco ou des contraintes OPA donne a un attaquant une feuille de route pour les contourner. Traitez les configurations de sécurité avec le même soin que les secrets.

Isolation du plan de management sécurité¶

Namespaces dédiés et isoles¶

Les composants de sécurité runtime sont déployés dans des namespaces dédiés, isoles du reste du cluster :

# Namespace Falco avec labels de classification
apiVersion: v1
kind: Namespace
metadata:
  name: falco-system
  labels:
    security.company.io/classification: "confidential"
    security.company.io/owner: "team-security"
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted

# Namespace Gatekeeper
apiVersion: v1
kind: Namespace
metadata:
  name: gatekeeper-system
  labels:
    security.company.io/classification: "confidential"
    security.company.io/owner: "team-security"
    pod-security.kubernetes.io/enforce: restricted

# Namespace Trivy
apiVersion: v1
kind: Namespace
metadata:
  name: trivy-system
  labels:
    security.company.io/classification: "confidential"
    security.company.io/owner: "team-security"
    pod-security.kubernetes.io/enforce: restricted

Network Policies strictes¶

Les namespaces de sécurité n'acceptent que les flux strictement nécessaires :

# NetworkPolicy : Falco
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: falco-network-policy
  namespace: falco-system
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    # Prometheus scrape
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - port: 8765
          protocol: TCP
  egress:
    # DNS
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
      ports:
        - port: 53
          protocol: UDP
    # Pousser les alertes vers Loki (via Alloy)
    - to:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - port: 3100
          protocol: TCP

# NetworkPolicy : Gatekeeper
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: gatekeeper-network-policy
  namespace: gatekeeper-system
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
  ingress:
    # API Server webhook calls
    - from: []  # L'API server n'a pas de label stable
      ports:
        - port: 8443
          protocol: TCP
    # Prometheus scrape
    - from:
        - namespaceSelector:
            matchLabels:
              name: monitoring
      ports:
        - port: 8888
          protocol: TCP
  egress:
    # DNS
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
      ports:
        - port: 53
          protocol: UDP

Accès restreint aux dashboards sécurité¶

RBAC Grafana pour le dossier Sécurité¶

Les dashboards de sécurité sont dans un dossier Grafana dedie avec des permissions restrictives :

Rôle Grafana	Accès au dossier Sécurité	Justification
Admin (équipe sécurité)	Edit	Créer et modifier les dashboards
security-viewer	View	Consulter les alertes et rapports
Autres équipes	Aucun	Pas d'accès aux informations de sécurité

Accès aux logs Falco dans Loki¶

L'accès aux logs de sécurité dans Loki est contrôle par le multi-tenancy :

# Configuration Loki : tenant "security" dedie
auth_enabled: true

limits_config:
  per_tenant_override_config: /etc/loki/tenant-overrides.yaml

# Les alertes Falco sont poussees avec tenant_id = "security"
# Seuls les utilisateurs avec le header X-Scope-OrgID = "security"
# peuvent les requeter

Separation des tenants Loki

Les alertes de sécurité doivent etre dans un tenant Loki separe des logs applicatifs. Un développeur qui a accès aux logs de son application ne doit pas pouvoir lire les alertes Falco qui révèlent les contrôles en place.

Intégrité des regles — GitOps et signature¶

GitOps pour les regles de sécurité¶

Les regles Falco, contraintes OPA et configurations Trivy sont versionnees dans un dépôt Git dedie et déployées par GitOps :

security-policies/
├── falco/
│   ├── rules/
│   │   ├── custom-rules.yaml
│   │   ├── classification-restricted.yaml
│   │   └── classification-confidential.yaml
│   └── kustomization.yaml
├── gatekeeper/
│   ├── templates/
│   │   ├── disallow-privileged.yaml
│   │   ├── allowed-repos.yaml
│   │   └── require-resource-limits.yaml
│   ├── constraints/
│   │   ├── no-privileged.yaml
│   │   ├── allowed-repos-prod.yaml
│   │   └── resource-limits-all.yaml
│   └── kustomization.yaml
├── trivy/
│   └── operator-config.yaml
└── kustomization.yaml

Contrôle d'accès au dépôt de politiques¶

Action	Qui	Processus
Modifier une regle	Équipe sécurité uniquement	PR + review obligatoire par un pair sécurité
Ajouter une exception	Équipe sécurité + approbation manager	PR + justification documentee + date d'expiration
Lire les regles	Équipe sécurité + équipe plateforme	Accès au dépôt Git restreint
Déployer les regles	ArgoCD (automatique)	Sync automatique depuis la branche main

# ArgoCD Application pour les politiques de securite
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: security-policies
  namespace: argocd
spec:
  project: security
  source:
    repoURL: https://git.internal.company.io/security/security-policies.git
    targetRevision: main
    path: .
  destination:
    server: https://kubernetes.default.svc
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=false

Signature des regles¶

Pour les environnements a haute sécurité, les manifestes de politiques sont signes avec Cosign :

# Signer un manifeste de politique
cosign sign-blob --key cosign.key \
  --output-signature falco-rules.sig \
  falco/rules/custom-rules.yaml

# Verifier avant deploiement (dans le pipeline CI)
cosign verify-blob --key cosign.pub \
  --signature falco-rules.sig \
  falco/rules/custom-rules.yaml

Separation des responsabilites

L'équipe sécurité écrit et maintient les regles. L'équipe plateforme opère les composants (Falco, Gatekeeper, Trivy). Aucune des deux équipes ne peut modifier les regles ET les déployer seule — le pipeline GitOps impose une revue croisee.

Audit des accès aux composants de sécurité¶

Tous les accès aux namespaces de sécurité sont journalises :

# Politique d'audit Kubernetes pour les namespaces securite
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Journaliser tous les acces aux namespaces de securite
  - level: RequestResponse
    namespaces: ["falco-system", "gatekeeper-system", "trivy-system"]
    resources:
      - group: ""
        resources: ["pods", "pods/exec", "pods/log", "configmaps", "secrets"]
  # Journaliser les modifications de contraintes OPA
  - level: RequestResponse
    resources:
      - group: "templates.gatekeeper.sh"
        resources: ["constrainttemplates"]
      - group: "constraints.gatekeeper.sh"
        resources: ["*"]
  # Journaliser les suppressions de rapports Trivy
  - level: RequestResponse
    verbs: ["delete"]
    resources:
      - group: "aquasecurity.github.io"
        resources: ["vulnerabilityreports"]

Référence¶

Pour le cadre général de classification et les regles par niveau, voir la rubrique Classification et zones de confiance.