Sécurité du proxy

Ce que ProxyAuthK8S applique, dans l'ordre, sur chaque requête proxifiée.

1. Bannissement (fail2login)

Vérifié avant toute chose, à partir de l'adresse du client — à ce stade aucun utilisateur n'est encore résolu.

security_config:
  enabled: true
  fail2login_equal_ban:
    enabled: true
    max_failed_logins: 5
    ban_duration: 300 # secondes ; 0 = bannissement permanent
    exponential_backoff: false

Chaque échec d'authentification incrémente un compteur Redis (fenêtre d'une heure). Au seuil, l'adresse est bannie et reçoit un 429 avec un en-tête Retry-After. Une authentification réussie remet le compteur à zéro.

Avec exponential_backoff, chaque échec au-delà du seuil double la durée, plafonnée pour qu'un compteur ancien ne produise pas un bannissement quasi permanent par accident.

2. Authentification

Selon auth_config.validate_against :

• OidcProvider : le jeton est présenté au endpoint userinfo du provider ;
• Kubernetes : le jeton est validé par un SelfSubjectReview sur le cluster cible.

auth_config.disable_validation: true désactive complètement cette étape — le proxy relaie alors sans savoir qui appelle.

Validation d'audience (OIDC)

userinfo prouve que le jeton est valide pour l'issuer, mais pas qu'il a été émis pour ce service : sans contrôle, n'importe quel access-token d'une autre application du même IdP serait accepté. Après userinfo, le proxy vérifie donc que l'audience du jeton correspond à l'audience attendue :

1. par introspection RFC 7662 si le provider expose un endpoint ;
2. sinon en lisant le claim aud du JWT (sûr ici, puisque userinfo a déjà validé la signature).

Seul le claim aud est comparé. azp/client_id désignent le client auquel le jeton a été délivré, pas la ressource visée ; les accepter rouvrirait le trou de confusion d'audience (un jeton aud=["autre-api"], azp=<ce service> passerait).

L'audience attendue et l'acceptation de azp se configurent par cluster, sur le provider OIDC du ProxyKubeApi :

auth_config:
  oidc_provider:
    enabled: true
    issuer_url: https://idp.example.com
    client_id: proxy-auth-k8s
    # audience attendue dans `aud`. Vide => on retombe sur `client_id`.
    audience: proxy-auth-k8s
    # accepte un jeton dont `aud` ne nomme pas ce service mais dont `azp`/`client_id` le fait.
    # À n'activer que pour les IdP (ex. Keycloak) émettant des jetons « self-audience ».
    accept_authorized_party: false

OAuth Authorization Server médiée (RFC 8414 + RFC 6749/PKCE)

À l'image d'OpenShift, un cluster peut exposer son propre serveur d'autorisation OAuth 2.0, sans passer par un oauth2-proxy dédié :

auth_config:
  oidc_provider:
    enabled: true
    issuer_url: https://idp.example.com
    client_id: proxy-auth-k8s
    expose_oauth_authorization_server: true

Une fois activé, le proxy devient lui-même le serveur d'autorisation vu par l'appelant : il médie tout l'échange avec issuer_url, l'appelant externe n'a jamais besoin d'être enregistré auprès du fournisseur d'identité réel — ni même d'en connaître le nom d'hôte.

GET /clusters/{ns}/{cluster}/.well-known/oauth-authorization-server répond, sans authentification (la découverte doit être joignable avant qu'un appelant n'ait de jeton), avec un document RFC 8414 où issuer, authorization_endpoint, token_endpoint et jwks_uri sont tous des URLs du proxy lui-même :

GET  {issuer}/oauth/authorize   # démarre le flux, redirige vers le provider réel
GET  {issuer}/oauth/callback    # reçoit le retour du provider (usage interne)
POST {issuer}/oauth/token       # échange le code proxy contre les jetons du provider
GET  {issuer}/oauth/jwks        # miroir passif du jwks_uri du provider

Déroulé du flux (RFC 6749, code d'autorisation + PKCE) :

1. L'appelant ouvre /oauth/authorize avec son propre code_challenge (S256) et un redirect_uri loopback uniquement (http://localhost ou http://127.0.0.1, RFC 8252) ;
2. le proxy génère son propre couple PKCE, l'état de corrélation, mémorise l'appel (Redis, TTL court) et redirige vers l'authorization_endpoint réel du provider ;
3. après authentification, le provider redirige vers /oauth/callback ; le proxy échange le code côté serveur (le client_secret du provider ne quitte jamais le proxy), vérifie le jeton d'identité, puis émet son propre code à usage unique et redirige l'appelant vers son redirect_uri d'origine ;
4. l'appelant échange ce code contre les jetons du provider sur /oauth/token, en prouvant la possession du code_verifier correspondant à son code_challenge initial.

Le jeton obtenu est un jeton Bearer valide pour ce cluster, puisque le proxy valide déjà les jetons bruts du provider via userinfo.

3. Autorisation par cluster

proxy_group: operators # groupe requis pour utiliser ce cluster
dashboard_group: viewers # groupe requis pour le voir dans le dashboard
expose_via_dashboard: true

L'ordre de résolution :

1. proxy_group explicite → c'est lui qui s'applique ;
2. sinon, si expose_via_dashboard est vrai → le dashboard_group s'applique aussi au proxy ;
3. sinon → aucune restriction de groupe.

4. Liste des ressources autorisées

security_config:
  enabled: true
  allowed_resources:
    - Path:
        path: /api/v1/namespaces/{{group}}/pods/**
        parametised: true
    - Path:
        path: /api/v1/namespaces/dev/configmaps

Une liste vide (le défaut) autorise tout. Sinon la requête doit correspondre à au moins une règle, sans quoi elle reçoit un 403 avec un objet Status Kubernetes — ce que kubectl sait afficher lisiblement.

Sémantique des motifs, uniquement quand parametised: true :

Sans parametised, la comparaison est exacte : un * y est un caractère littéral.

Règles par ressource (group/version/kind)

Au lieu d'un chemin, une règle peut cibler une ressource et appliquer des restrictions par namespace :

security_config:
  enabled: true
  allowed_resources:
    - Crd:
        group: example.com # "" pour le groupe core (/api/v1/...)
        version: v1
        kind: Widget
        plural: widgets # sinon le kind en minuscules est utilisé
        namespaced: true
        namespace:
          enabled: true
          rule_kind:
            ParametisedRule: 'dev-{{username}}' # ou AllowedNamespaces / DeniedNamespaces

Le chemin est reconnu sous ses formes namespacée (.../namespaces/{ns}/{plural}) et cluster-wide (.../{plural}). Les règles de namespace :

Ces règles sont aussi appliquées à l'admission par des règles CEL sur le CRD : un chemin relatif ou un placeholder inconnu est refusé par l'apiserver, pas seulement au reconcile.

5. Quotas

security_config:
  enabled: true
  rate_limiting:
    enabled: true
    max_requests_per_minute: 60
  per_user_group_rate_limiting:
    - group: power-users
      max_requests_per_minute: 600
    - group: admins
      max_requests_per_minute: 0 # 0 = illimité

Le décompte se fait par utilisateur une fois celui-ci résolu (sinon par adresse), pour qu'un NAT partagé ne fasse pas partager un budget. Une entrée de groupe l'emporte sur le réglage global, et quand un utilisateur appartient à plusieurs groupes configurés, le plus permissif gagne : appartenir à un groupe de plus ne doit jamais restreindre.

En-têtes transmis

Le proxy est seul maître de trois en-têtes, systématiquement retirés de la requête cliente puis reconstruits :

Sont également retirés de la requête cliente (sur le chemin standard comme upgrade) tous les en-têtes d'identité que l'apiserver interprète directement : Impersonate-* (impersonation native Kubernetes) et X-Remote-* (noms conventionnels de l'authentification requestheader). Sans quoi, si l'apiserver est câblé sur ces noms, un client pourrait envoyer X-Remote-User: system:admin ou Impersonate-User: … et usurper une identité à travers le certificat front-proxy de confiance. Le header Authorization du client, lui, reste transmis : c'est le seul credential amont en mode validate_against: Kubernetes sans mTLS.

Journal d'audit

Chaque requête proxifiée émet un évènement tracing sur la cible audit, qui traverse le pipeline OpenTelemetry existant :

L'évènement est émis dès que l'amont répond, pas à la fin du flux : un watch reste ouvert plusieurs minutes et attendre sa fin retarderait l'enregistrement d'autant.

Pour ne router que l'audit :

RUST_LOG=warn,audit=info

mTLS vers le cluster cible

cert:
  Secret: { name: cluster-ca, key: ca.crt }
client_cert:
  cert:
    Secret: { name: proxy-client-cert, key: tls.crt }
  key:
    Secret: { name: proxy-client-cert, key: tls.key }

Le certificat client est présenté à l'apiserver sur le chemin standard comme sur les connexions upgrade (exec, attach, port-forward).

Un Secret/ConfigMap de certificat peut cibler un namespace explicite. Par défaut c'est refusé (sécurisé par défaut) : la lecture utilise le ServiceAccount cluster-wide du controller et les octets résolus finissent dans le certificate_authority_data du kubeconfig rendu, donc autoriser un namespace arbitraire ferait d'un tenant capable de créer un ProxyKubeApi un oracle de lecture de Secret cross-namespace. Chaque lecture est donc épinglée au namespace du CR. Sur un cluster mono-tenant où tous les auteurs de CR sont déjà de confiance, positionnez PROXYAUTH_ALLOW_CROSS_NS_CERT=true pour réautoriser le champ namespace.

Cible upstream (SSRF)

La cible d'un cluster est définie par un administrateur dans le ProxyKubeApi (Service), pas par le client. Un KubernetesService résout une Service Kubernetes réelle ; un ExternalService prend une URL telle quelle (préférez https : en mode validate_against: Kubernetes le Bearer du client est transmis à cette URL, donc http l'exposerait en clair). Deux garde-fous limitent un détournement :

• le client HTTP amont ne suit aucune redirection — un apiserver ne redirige pas les appels API proxifiés, et suivre un 30x laisserait une cible autorisée renvoyer la requête (et le jeton) vers un hôte non prévu (ex. l'endpoint metadata) ;
• la NetworkPolicy du chart exclut par défaut 169.254.0.0/16 (endpoint metadata cloud) et 100.64.0.0/10 de l'egress externe.

Comme la cible est administrée via CRD, restreignez qui peut créer/éditer des ProxyKubeApi (RBAC) sur un cluster multi-tenant.

Variables d'environnement de sécurité

Limites de mémoire

Risques acceptés / différés

Décisions produit tracées pour les points de durcissement volontairement laissés en l'état. Chacun est un choix conscient, avec sa mitigation ; réévaluez-les selon votre modèle de menace.