Problème d'auth LDAP Vault avec user-DN exotique

Question

Salut la team secops un peu bloqué là
on essaie de configurer l'auth LDAP sur Vault notre AD est un peu spécial les users sont pas sous un simple ou=users mais plutot un truc genre ou=People,ou=Accounts,dc=monentreprise,dc=com et j'ai l'impression que Vault galère à trouver les users même si mon user_dn_template semble correct

path "ldap" {
  tune {
    default_lease_ttl = "1h"
    max_lease_ttl = "24h"
  }
}

vault write auth/ldap/config \
  url="ldap://ldap.monentreprise.com" \
  binddn="cn=vault-bind,ou=ServiceAccounts,dc=monentreprise,dc=com" \
  bindpass="supersecurepassword" \
  userdn="ou=People,ou=Accounts,dc=monentreprise,dc=com" \
  groupdn="ou=Groups,dc=monentreprise,dc=com" \
  userattr="sAMAccountName" \
  groupattr="memberOf" \
  insecure_tls=false \
  starttls=true
# user_dn_template ça je l'ai pas mis directement dans la config
# je le configure après avec un vault write auth/ldap/users/ldap_user policies=default user_dn=cn={{.username}},ou=People,ou=Accounts,dc=monentreprise,dc=com

quand je tente de me login avec mon username ça me dit "no matching user found" mais le binddn fonctionne. des idées ?

idurand · Answer

hello bah le truc classique c de jouer avec le for. mais si tu veux pas ça la solution c des labels dynamiques sur tes pods. quand tu déploies tu ajoutes un label genre "monitoring=paused" et ton alerte rule exclut ces pods
ou alors mieux dans ta règle prometheus tu ajoutes un unless ou and on(pod, namespace) (kube_pod_status_phase != "pending") ou des choses comme ça. regarde les metrics kube_pod_status_phase kube_pod_status_condition

laurent01 · Answer

ouais j'ai déjà le kube_pod_status_phase == "running" pour éviter les pending ou terminated. mais les pods en init sont "running" avant d'être "ready"
le label dynamique c'est une option mais ça veut dire intégrer ça dans mon CI/CD c'est pas ouf

idurand · Answer

ok je vois. alors la solution propre c'est kube_pod_container_status_started{job="kube-state-metrics", container=~".+"} == 1. ça indique si le container a commencé à tourner. si tu combines ça avec ready et une durée tu peux filter
ou alors regarde la condition Initialized ou ContainersReady via kube_pod_status_condition{condition="Initialized", status="true"} ça te donne quand les init containers sont passés. tu peux ajouter un for: 30s sur cette condition

laurent01 · Answer

hum kube_pod_container_status_started c'est intéressant ça. si je dis podnotready et container est started depuis moins de x minutes alors pas d'alerte. ça peut être pas mal

idurand · Answer

exactement. tu peux faire un truc du genre :

sum by (namespace, pod) (
  kube_pod_container_status_ready{container=~".+"} == 0
  and
  kube_pod_status_phase == "Running"
  and
  # et là tu ajoutes une condition sur le temps depuis le démarrage du container
  # par exemple, on alerte que si le container est démarré depuis plus de 5min
  # faut trouver la bonne métrique de temps de démarrage
  # ou utiliser `kube_pod_container_status_started` avec un offset
) > 0

c plus complexe à écrire mais beaucoup plus précis pour éviter le bruit

laurent01 · Answer

ok je vois. en fait j'ai trouvé un truc plus simple en combinant kube_pod_status_condition{condition="Ready", status="false"} avec un truc pour dire que le pod est plus jeune que 5min. comme ça les pods qui viennent de spawn sont ignorés. ça a l'air de marcher avec ma phase de rollout. je vais tester ça en prod

idurand · Answer

nickel. l'essentiel c de trouver la métrique qui reflète le "je suis en train de me setup" et l'exclure du périmètre d'alerte pour une courte période. thx pour le feedback

Problème d'auth LDAP Vault avec user-DN exotique

7 commentaires

Laisser une réponse

Les packages dans le langage de programmation Go

Filtrer les sorties Kubernetes

Installer et configurer votre environnement Terraform

Les bonnes pratiques du DevOps

Maximiser la productivité du DevOps grâce à ChatGpt

Rejoindre la communauté