Comments 13
Он безопасно хранит ключи и управляет ими.
Ну допустим мы всё вот это вот сделали, а дальше что? Как конечное приложение, запущенное в поде, получает доступ к секрету? Если через маунты, то от каких векторов атаки всё описанное в результате защищает? Получили доступ к любому поду - получили в открытом виде все имеющиеся у него секреты.
В pod можно использовать секрет вот так
apiVersion: v1
kind: Pod
metadata:
name: mypod
spec:
containers:
- name: mypod
image: redis
volumeMounts:
- name: foo
mountPath: "/etc/foo"
readOnly: true
volumes:
- name: foo
secret:
secretName: mysecret
optional: true
Источник примера https://kubernetes.io/docs/concepts/configuration/secret/
У злоумышленника не должно быть возможности залезть в под. А админы кластера и так по определению имеют доступ к секретам. Никакого противоречия здесь нет.
В чем преимущество approle перед kubernetes auth?
Kubernetes auth как я понял позволяет использовать short-lived token, что выглядит безопаснее
Зачем в kubernetes так все усложняют?
Костыль на костыле костылем погоняя и забито шурупами...
Как вы храните секреты от appRole?
Как масштабируете, управляете этим делом?
Тоже интересно про масштабирование. Если микросервисов штук 300 и в каждом 2-3 секрета
Как создавать Kubernetes секреты из Vault, используя external-secrets-operator