c
Size: a a a
2020 December 09
С
в волте для kubernetes auth бекенда должна быть роль ещё, какие там настройки?
c
vault write auth/kubernetes/role/internal-app \
bound_service_account_names=internal-app \
bound_service_account_namespaces=default \
policies=internal-app \
ttl=24h
c
все по оф. доке собирал
Р
Всем привет, кто нибудь в курсе что может быть? job висит в состоянии 1 Queued
в логах тишина. Nomad
в логах тишина. Nomad
С
все по оф. доке собирал
Сервисаккаунт токен в поде с сервисом отдельный? Если нет, то должно быть default в роли. Под в неймспейс default выкатывается?
Попробуй вообще bound_... убрать из настроек.
Попробуй вообще bound_... убрать из настроек.
c
Сервисаккаунт токен в поде с сервисом отдельный? Если нет, то должно быть default в роли. Под в неймспейс default выкатывается?
Попробуй вообще bound_... убрать из настроек.
Попробуй вообще bound_... убрать из настроек.
если не ошибаюсь это же обязательные поля и в кластере где vault крутится, все ок, а вот на другом кластере для которого vault является external — печаль
по поводу токена, в ошибку выпадает контейнер vault-agent-init
по поводу токена, в ошибку выпадает контейнер vault-agent-init
С
если не ошибаюсь это же обязательные поля и в кластере где vault крутится, все ок, а вот на другом кластере для которого vault является external — печаль
по поводу токена, в ошибку выпадает контейнер vault-agent-init
по поводу токена, в ошибку выпадает контейнер vault-agent-init
Вот у этого пода, куда катится инит, должен совпадать неймспейс и сервисаккаунт токен с теми, что ты пишешь в роль.
С
Если ты в поде дополнительный не создавал никакой, то исползуется default, а не internal-app. И неймспейс првоерь
С
И ты можешь "*" поставить, тогда любой примется. Но
If set to "*" all namespaces are allowed, both this and bound_service_account_names can not be set to "*".
If set to "*" all namespaces are allowed, both this and bound_service_account_names can not be set to "*".
c
Если ты в поде дополнительный не создавал никакой, то исползуется default, а не internal-app. И неймспейс првоерь
2020-12-09T09:49:10.888Z [ERROR] auth.kubernetes.auth_kubernetes_0dfed0ee: login unauthorized due to: lookup failed: service account unauthorized; this could mean it has been deleted or recreated with a new tokenдело, в том, что в другом кластере такой же конфиг ок работает и секреты прокидываются
С
2020-12-09T09:49:10.888Z [ERROR] auth.kubernetes.auth_kubernetes_0dfed0ee: login unauthorized due to: lookup failed: service account unauthorized; this could mean it has been deleted or recreated with a new tokenдело, в том, что в другом кластере такой же конфиг ок работает и секреты прокидываются
Тогда проверь, что ты не перепутал кластеры. У тебя в config должны быть параметры из кластера, в котором будет запускаться под.
c
- серт положил от домена верный(если бы не верный он бы с логе ругнулся на x509)
- jwt_token положил, который создал официальный hashicorp vault чарт
- k8s_host тоже верный ( и k cluster-info)
- jwt_token положил, который создал официальный hashicorp vault чарт
- k8s_host тоже верный ( и k cluster-info)
c
Тогда проверь, что ты не перепутал кластеры. У тебя в config должны быть параметры из кластера, в котором будет запускаться под.
тоесть, правильно ли понимаю
vault agent init берет токен из сервис аккаунта и идет на vault по апишке за секретом, а тот его разворачивает с permission denied
тоесть проблема в том, что токены не совпадают?
vault agent init берет токен из сервис аккаунта и идет на vault по апишке за секретом, а тот его разворачивает с permission denied
тоесть проблема в том, что токены не совпадают?
С
тоесть, правильно ли понимаю
vault agent init берет токен из сервис аккаунта и идет на vault по апишке за секретом, а тот его разворачивает с permission denied
тоесть проблема в том, что токены не совпадают?
vault agent init берет токен из сервис аккаунта и идет на vault по апишке за секретом, а тот его разворачивает с permission denied
тоесть проблема в том, что токены не совпадают?
Всё сложнее. Агент идёт в волт за волтовым токеном, приносит сервисаккаунт токен. Чтобы выдать токен, волт идёт в кластер(кластер, где работает агент!) с креденшелами из config и убеждается, что агент в правильном поде и неймспейсе. Если всё ок, волт выдаёт токен, и агент уже с волтовым токеном идёт за секретами.
c
тоесть самый простой дебаг это брать сервис аккаунт токен и прямо через ui например пытаться авторизироваться?
c
Всё сложнее. Агент идёт в волт за волтовым токеном, приносит сервисаккаунт токен. Чтобы выдать токен, волт идёт в кластер(кластер, где работает агент!) с креденшелами из config и убеждается, что агент в правильном поде и неймспейсе. Если всё ок, волт выдаёт токен, и агент уже с волтовым токеном идёт за секретами.
у меня есть service_account vault, созданный хелмом, который связан с clusterRoleBinding (system:auth-delegator)
он используется для того, что бы vault мог обращаться к аписерверу верно?
он используется для того, что бы vault мог обращаться к аписерверу верно?
С
у меня есть service_account vault, созданный хелмом, который связан с clusterRoleBinding (system:auth-delegator)
он используется для того, что бы vault мог обращаться к аписерверу верно?
он используется для того, что бы vault мог обращаться к аписерверу верно?
да
c
тогда более чем со 100% вероятностью можно сказать, что косяк именно тут?
ведь в деплойменте линкую этот сервис аккаунт
vault write auth/kubernetes/role/internal-app \но ya же не совсем криворукий, что повторив одну операцию 10 раз разными способами, получаю одну и ту же ошибку:)
bound_service_account_names=internal-app \
bound_service_account_namespaces=default \
policies=internal-app \
ttl=24h
ведь в деплойменте линкую этот сервис аккаунт
spec:
serviceAccountName: internal-app