Sécurité du proxy

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

1. Bannissement (fail2login)Copy Anchor Link

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. AuthentificationCopy Anchor Link

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 ;
• JwtAuthenticators : le jeton est validé localement contre les authenticators auth_config.jwt (voir Validation JWT locale).

Défaut : Kubernetes, le choix qui échoue en fermé et vaut pour n'importe quel cluster. Les deux autres modes se choisissent toujours explicitement, pour qu'un cluster ne change jamais de mode d'authentification parce qu'un champ a été ajouté ailleurs dans le spec.

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

Validation JWT locale (JwtAuthenticators)Copy Anchor Link

Reproduit la structured authentication configuration de l'apiserver : le jeton est vérifié sur place, sans aucun aller-retour vers le provider ni vers le cluster cible sur le chemin de la requête.

auth_config:
  validate_against: JwtAuthenticators
  jwt:
    - issuer:
        url: https://issuer.example.com
        audiences: ["proxyauthk8s"]
      claim_validation_rules:
        - claim: hd
          required_value: example.com
        # ou, en CEL :
        - expression: "claims.email.endsWith('@example.com')"
          message: "seules les identités example.com sont acceptées"
      claim_mappings:
        username:
          claim: sub
          prefix: "oidc:"
        groups:
          claim: groups
          prefix: ""
        extra:
          - key: email
            value_expression: claims.email
      user_validation_rules:
        - expression: "!user.username.startsWith('system:')"
          message: "un username ne peut pas utiliser le préfixe réservé system:"

L'ordre n'est pas un détail d'implémentation : rien n'est cru avant la vérification de signature, les claim_validation_rules s'appliquent à des claims déjà vérifiés, et les user_validation_rules s'appliquent à l'identité déjà mappée — c'est le seul moment où le username final est connu, donc le seul endroit où l'on peut empêcher un IdP de forger un nom privilégié.

1. lecture de iss dans la charge utile non vérifiée, uniquement pour choisir l'authenticator — iss est ensuite re-contrôlé pendant la vérification de signature, donc un iss forgé sélectionne un authenticator dont la clé rejettera le jeton ;
2. récupération de la JWKS de l'issuer (via son document de découverte), avec cache ;
3. vérification de la signature, puis de exp, nbf, iss et aud ;
4. claim_validation_rules ;
5. claim_mappings → username, groups, uid, extra ;
6. user_validation_rules sur l'utilisateur mappé.

Les expressions CEL disposent de la bibliothèque d'extensions Kubernetes (strings, lists, sets, regex, urls, ip, …) : une expression copiée depuis une configuration d'apiserver s'y comporte de la même façon, plutôt que sur un sous-ensemble à découvrir à l'usage.

Validation d'audience (OIDC)Copy Anchor Link

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).

Un client public (PKCE, sans client_secret) ne peut pas s'authentifier auprès de l'introspection, et certains IdP (authentik) lui répondent active: false. Dans ce cas seulement, le proxy ne prend pas cette réponse pour une révocation et retombe sur le claim aud du JWT.

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

Configuration OIDC dans un Secret externe (config_from)Copy Anchor Link

Le client_secret écrit directement dans le ProxyKubeApi est lisible par quiconque a le droit get sur la ressource, apparaît dans un kubectl get -o yaml et se retrouve dans chaque sauvegarde de l'objet. oidc_provider.config_from permet de ne garder qu'une référence dans le CR, le secret vivant dans l'objet que les opérateurs protègent déjà — et que external-secrets sait alimenter :

auth_config:
  oidc_provider:
    enabled: true
    config_from:
      Secret:
        name: oidc-config
        # namespace: shared   # voir l'encart ci-dessous

Les clés du Secret sont les noms de champs de oidc_provider, en snake_case :

Règles de résolution :

• une clé présente dans le Secret l'emporte sur la valeur en ligne ;
• une clé absente retombe sur la valeur en ligne, donc un Secret partiel — le cas courant : seulement client_secret — fonctionne, le reste restant lisible dans le CR ;
• les clés hors de cette liste sont ignorées : un Secret géré par external-secrets est couramment partagé avec d'autres consommateurs, une clé inconnue ne doit pas faire échouer le bloc ;
• un Secret ne portant aucune des clés ci-dessus est en revanche une erreur : c'est presque toujours une faute de frappe, et retomber silencieusement sur le bloc en ligne que l'opérateur cherchait justement à remplacer serait le pire des comportements ;
• un Secret illisible ou absent est une erreur : la résolution échoue en fermé, elle ne retombe jamais sur le bloc en ligne.

Les interrupteurs de politique (enabled, accept_authorized_party, expose_oauth_authorization_server) ne sont volontairement pas lisibles depuis le Secret : ils décident de la sévérité de la validation des jetons et de qui atteint le cluster, ils doivent donc rester visibles dans le CR que l'admission et la revue regardent.

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

À 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 clusterCopy Anchor Link

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éesCopy Anchor Link

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)Copy Anchor Link

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.

Ports autorisésCopy Anchor Link

allowed_ports limite les ports qu'un utilisateur peut ouvrir, sur une règle Path ou sur une règle Crd de kind Pod ou Service :

security_config:
  enabled: true
  allowed_resources:
    - Path:
        path: /api/v1/namespaces/dev/pods/*/portforward
        parametised: true
        allowed_ports: ["8080", "9000-9100"]
    - Crd:
        group: ""
        version: v1
        kind: Service
        plural: services
        namespace: { enabled: true, rule_kind: { AllowedNamespaces: ["dev"] } }
        allowed_ports: ["80"]

La politique s'applique à tous les chemins qui ouvrent un port :

• allowed_ports accepte des ports seuls ("8080") ou des plages inclusives ("9000-9100"), entre 1 et 65535. L'admission refuse un port hors bornes ("0", "70000"), une plage inversée ("200-100") ou allowed_ports sur une règle Crd d'un autre kind que Pod et Service. Une entrée invalide déjà stockée est signalée et n'autorise aucun port.
• Restriction. Dès qu'une règle qui concerne l'utilisateur porte allowed_ports, quel que soit son chemin, ses ports sont restreints. Une règle Path n'a pas de sujet : une seule règle Path avec allowed_ports restreint tous les utilisateurs du cluster. Une règle Crd dont la règle de namespace paramétrée ne donne aucun candidat pour l'utilisateur (un {{group}} sans groupe) ne le restreint pas.
• Ports accordés. Sous restriction, ce sont ceux des règles qui correspondent au chemin et portent allowed_ports. Une règle sans allowed_ports (une Crd Pod, un .../pods/**) n'accorde aucun port, mais continue d'autoriser ses autres chemins (get pods, logs…). Une liste vide (allowed_ports: []) n'accorde aucun port.
• Sans aucune règle allowed_ports, ou avec security_config.enabled: false, rien n'est restreint, nodes/proxy compris.

Ports nommés ou absents. pods/web:http/proxy, services/web/proxy ou un port illisible sont refusés sous restriction (403 "named or missing port is not allowed on this cluster") : le proxy ne peut pas résoudre un nom sans lire l'objet, et un nom est choisi par qui écrit le pod. Le segment est décodé une fois, comme le fait l'apiserver : web%3A5432 vaut web:5432, et web%253A5432 est un nom sans port, donc refusé.

Ports d'un Service. Sur services/{nom}:{port}/proxy, {port} est un port du Service, pas son targetPort, et seule une règle qui couvre services/... peut l'accorder (une règle pods n'accorde jamais rien sur un Service). Qui peut modifier un Service choisit son targetPort : limitez l'écriture des services par le RBAC du cluster cible.

nodes/proxy. Ce chemin atteint l'API du kubelet (/portForward, /exec) sans passer par les contrôles de l'apiserver. Sous restriction de ports ou de verbes, il est refusé (403 "nodes/proxy is not allowed while ports, verbs or exec are restricted"), sauf si une règle Path qui autorise le chemin le vise explicitement, avec nodes et proxy en segments littéraux :

    - Path:
        path: /api/v1/nodes/*/proxy/**
        parametised: true

Une règle Crd Node ou un Path /api/v1/nodes/** ne comptent pas, et sont signalés dans status.warnings.

Où le proxy lit les ports d'un port-forward. kubectl ne met pas les ports dans l'URL : il ouvre un flux SPDY par port, tunnelé dans la websocket (sous-protocole SPDY/3.1+portforward.k8s.io), et le port est un en-tête compressé de chaque flux. Le proxy décode donc le trafic client de la session et vérifie chaque nouveau flux avant de le transmettre. Avec les protocoles websocket « canal » (v4.channel.k8s.io), les ports sont dans le paramètre ports de l'URL et sont vérifiés avant de contacter le cluster (403 sinon). Les politiques sont vérifiées avant le contrôle « websocket seulement » : le repli SPDY de kubectl reçoit le même 403 et sa raison, et non « SPDY is not supported ».

Au premier port refusé, toute la session est fermée ; le flux refusé n'atteint jamais le cluster. Tout ce que le proxy ne sait pas lire (extension websocket comme permessage-deflate, sous-protocole inconnu, trame SPDY invalide) ferme aussi la session : un port illisible est traité comme un port refusé.

Traçabilité. Chaque décision écrit une ligne d'audit policy_decision (policy: port, decision parmi allowed, denied, node_proxy_denied, closed_by_filter, et port quand il est lisible, voir Journal d'audit), et incrémente proxyauth_policy_decisions_total{cluster, policy="port", decision} sur l'endpoint Prometheus, avec les mêmes valeurs de decision.

Verbes autorisésCopy Anchor Link

verbs limite les verbes Kubernetes qu'une règle Path ou Crd autorise :

allowed_resources:
  - Path:
      path: /api/v1/namespaces/dev/pods/**
      parametised: true
      verbs: [get, list, watch]          # lecture seule
  - Crd:
      group: ""
      version: v1
      kind: ConfigMap
      plural: configmaps
      namespace: { enabled: true, rule_kind: { AllowedNamespaces: ["dev"] } }
      verbs: ["*"]                        # tous les verbes, explicitement

Valeurs : get, list, watch, create, update, patch, delete, deletecollection, ou * seul. L'admission refuse une liste vide, une valeur inconnue et * accompagné d'autres verbes.

Le verbe est calculé comme le fait l'apiserver, pas à partir de la seule méthode HTTP :

• Restriction. Dès qu'une règle qui concerne l'utilisateur déclare verbs, ses verbes sont restreints (même définition que pour les ports : une règle Path restreint tout le cluster). Une règle sans verbs ne lui accorde alors que get, list et watch.
• create implicite. allowed_ports accorde create sur …/portforward (pas sur …/proxy, qui reste soumis aux verbs).
• Refus. Sous restriction, un verbe qu'aucune règle n'accepte donne 403 verb "delete" is not allowed on "<chemin>". Un verbe indéterminable (méthode inconnue, ancien préfixe /proxy/, méthode autre que GET sur un chemin non ressource) est refusé. Les politiques de ports ne regardent que les règles qui ont accepté chemin et verbe.
• Règles Crd. Leurs verbs couvrent toutes les sous-ressources : une Crd Pod avec patch ou update autorise aussi PATCH …/ephemeralcontainers, donc kubectl debug, et status.warnings le signale. Une règle qui couvre exec/attach/portforward sans create est signalée aussi.
• nodes/proxy. Un GET sur nodes/{n}/proxy/exec/… vaut get : sous restriction de verbes, il est refusé comme sous restriction de ports, sauf règle Path explicite nodes/*/proxy.
• API virtuelles. Le verbe est vérifié sur la requête d'origine et sur la requête réécrite : delete sur un Project virtuel n'ouvre pas un delete sur le namespace.
• L'en-tête X-HTTP-Method-Override est retiré de la requête relayée ; le verbe est toujours calculé sur la méthode réelle.
• Sans aucune règle verbs, rien ne change.

Exec et attachCopy Anchor Link

Une règle Path ou Crd (kind: Pod seulement) peut porter une politique exec qui limite ce que pods/{nom}/exec et pods/{nom}/attach permettent :

allowed_resources:
  - Path:
      path: "/api/v1/namespaces/dev/pods/*/exec"
      parametised: true
      exec:
        commands:
          - ["ls", "**"]                 # ls avec n'importe quels arguments
          - ["cat", "/var/log/app/*"]    # cat d'un fichier de ce dossier
          - ["/app/bin/healthcheck"]     # exactement cette commande
        containers: ["app"]              # absent : tous ; [] : aucun
        stdin: false                     # défaut false
        tty: false                       # défaut false (tty demande stdin)
  - Path:
      path: "/api/v1/namespaces/dev/pods/*/attach"
      parametised: true
      exec: { containers: ["app"], attach: true }

• Une règle accepte entièrement, ou pas. Une requête passe si une règle accepte à la fois sa commande, son conteneur et ses flux. Deux règles ne se combinent jamais : ls dans app et env dans sidecar n'autorisent ni env dans app, ni ls dans sidecar.
• Restriction par utilisateur. Dès qu'une règle qui vous concerne déclare exec, seules les règles qui correspondent au chemin et déclarent exec accordent un exec ou un attach. Une règle large (…/pods/**, /api/v1/namespaces/**, Crd Pod) n'en accorde plus aucun, même dans un autre namespace. Une règle Path n'a pas de sujet : une seule règle Path avec exec restreint tous les utilisateurs du cluster.
• Commandes. Comparées élément par élément ; * couvre un élément ou une partie, ** (en dernier seulement) zéro élément ou plus. Pas de normalisation : ls et /bin/ls diffèrent. Un motif qui commence par un shell ou un interpréteur (sh, bash, python*, env, find, xargs…) et contient un joker est signalé dans status.warnings : il autorise tout. Un interpréteur avec un argv exact (["sh", "-c", "/app/bin/rotate-logs"]) est une commande exacte.
• Conteneur. Sous restriction de containers, la requête doit nommer son conteneur ; kubectl le fait toujours (-c, ou le conteneur par défaut qu'il résout lui-même).
• Attach. Il faut une règle qui couvre …/pods/*/attach, déclare exec et a attach: true (commands y est ignoré). Une règle …/pods/*/exec seule n'accorde pas l'attach.
• Protocoles. Sous restriction, seuls v5.channel.k8s.io et v4.channel.k8s.io (binaires, sans extension websocket) sont acceptés : le proxy doit pouvoir lire le canal de chaque message.
• Requêtes ambiguës. Un paramètre container, stdin, stdout, stderr ou tty répété, ou un ; dans la query, reçoit un 400 : l'apiserver garderait la première valeur, le proxy refuse. Une valeur vide (stdin=) vaut « vrai », comme pour l'apiserver.
• nodes/proxy. Sous restriction d'exec, nodes/{n}/proxy/** (donc l'exec du kubelet) est refusé, comme sous restriction de ports ou de verbes, sauf règle Path explicite nodes/*/proxy.

kubectl cp. Copier vers le pod lance tar -xmf - avec stdin : il faut stdin: true et le motif ["tar", "**"] (plus ["test", "**"], que kubectl lance avant). Copier depuis le pod lance tar cf - <chemin> sans stdin : ["tar", "cf", "-", "**"] suffit. Piège : avec --retries, kubectl lance sh -c "tar cf - … | tail -c+N", un shell, donc refusé sauf motif interpréteur.

Audit. Chaque ligne d'un exec porte l'objet exec (voir Journal d'audit). Une décision écrit policy_decision (policy: exec, allowed, ou denied avec reason parmi command, container, stdin, tty, attach, no_rule), et session_closed porte les octets de chaque canal (channel_bytes) et, si le filtre a coupé, channel.

5. QuotasCopy Anchor Link

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 transmisCopy Anchor Link

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. Exception : en upstream_auth.mode: FrontProxy (RFC 0014), Authorization et x-forwarded-* sont retirés et le proxy affirme lui-même l'identité, préfixée, en X-Remote-* sur son certificat front-proxy ; en Issuer, Authorization est remplacé par un JWT que le proxy signe. Modèles de confiance et risques acceptés dans Apiserver en front-proxy et Le proxy comme émetteur.

Journal d'auditCopy Anchor Link

Chaque décision de sécurité écrit une ligne JSON sur stdout, dans un schéma versionné (audit_schema: 1, RFC 0008). Ces lignes sortent toujours : RUST_LOG ne les filtre pas, et elles restent en JSON même avec LOG_FORMAT=text (elles se mêlent alors aux logs texte ; le collecteur les reconnaît au champ "audit_schema"). Il n'existe aucun réglage pour les couper : le tri se fait au collecteur. L'écriture est synchrone : si stdout bloque, la requête attend plutôt que de passer sans trace.

Champs communs à chaque ligne :

request et policy_decision ajoutent http_method, k8s_verb (le verbe Kubernetes, calculé comme l'apiserver), path (sans la query string), status, latency_ms et upstream_via (direct, ou agent pour un cluster joint par son tunnel), et upstream_mode (Passthrough, FrontProxy ou Issuer, RFC 0014 : comment l'identité est présentée à l'apiserver). Pour une API virtuelle, upstream_path et upstream_k8s_verb décrivent la requête réécrite. Quand l'apiserver refuse un upgrade (exec, attach, port-forward), upstream_reason reprend le message de son Status (256 caractères au plus).

Pour un exec ou un attach, chaque ligne de la requête (request, policy_decision, session_closed) porte un objet exec : argv (la commande, élément par élément), container, stdin et tty, tels que l'apiserver les lit dans la query. La commande est écrite en entier, y compris un mot de passe passé en argument (mysql -pSECRET). Avec security_config.mask_exec_secrets: true, ce qui ressemble à un secret est remplacé par *** (-pSECRET, --password=SECRET, --token=SECRET, et l'élément qui suit -p, --password ou --token) : une heuristique, pas une garantie, désactivée par défaut.

Une ligne ne contient jamais l'en-tête Authorization, un jeton (d'accès, de rafraîchissement, d'identité), un code d'autorisation, un client_secret, une query string ni un corps : ses champs sont une liste fermée.

proxyauth_audit_events_total{event, outcome} compte les lignes écrites, et proxyauth_session_duration_seconds{kind} mesure la durée des tunnels (kind parmi exec, attach, portforward, proxy, other). Exemple de règle d'alerte : increase(proxyauth_audit_events_total{event="client_banned"}[5m]) > 10.

Connexions upgrade (exec, attach, port-forward)Copy Anchor Link

Seules les connexions websocket sont tunnelées. Un Upgrade: SPDY/3.1 reçoit un 400 explicite sans que le cluster soit contacté : le serveur HTTP du proxy ne transmet pas au gestionnaire les octets qui suivent une poignée de main SPDY, la session mourrait juste après son 101. Les versions récentes de kubectl utilisent la websocket par défaut pour exec, attach et port-forward.

Quand l'apiserver refuse la websocket (un exec sur un pod Pending, par exemple), kubectl retente en SPDY et n'affiche que le 400 du proxy : la vraie raison est perdue pour l'utilisateur. Le message du 400 le dit (kubectl -v=6 montre la raison amont), et la ligne d'audit request de la tentative websocket porte cette raison dans upstream_reason.

Le proxy ne passe en mode tunnel qu'après un 101 Switching Protocols de l'apiserver, et seulement pour les chemins qui en ont besoin (exec, attach, portforward, proxy, watch). Toute autre réponse est renvoyée telle quelle puis la connexion est fermée, sans transmettre au cluster les octets envoyés par le client après sa requête : sinon une seconde requête cachée derrière la première échapperait à l'authentification, à la liste des ressources autorisées et au filtrage des en-têtes d'identité.

mTLS vers le cluster cibleCopy Anchor Link

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)Copy Anchor Link

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éCopy Anchor Link

Limites de mémoireCopy Anchor Link

Risques acceptés / différésCopy Anchor Link

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.