Как стать автором
Обновить

Комментарии 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/

Я и говорю, положили секреты в маунт в открытом виде, тем самым помножили на ноль всё что городили перед этим.

У злоумышленника не должно быть возможности залезть в под. А админы кластера и так по определению имеют доступ к секретам. Никакого противоречия здесь нет.

От того что вы объявили что у злоумышленника не должно быть такой возможности, RCE-уязвимости никуда вдруг не исчезли.

Существование таких уязвимостей не обесценивает концепцию секретов

Но всё-таки. От каких векторов атаки должно защитить описанное в статье?

В чем преимущество approle перед kubernetes auth?

Kubernetes auth как я понял позволяет использовать short-lived token, что выглядит безопаснее

Да, вы правы. Kubernetes auth позволяет использовать short-lived token, что выглядит безопаснее. Мое мнение что app-role проще, чем Kubernetes auth.

Зачем в kubernetes так все усложняют?

Костыль на костыле костылем погоняя и забито шурупами...

Это не "в кубернетес". Это хашикорп пытается продать свой софт.

Как вы храните секреты от appRole?
Как масштабируете, управляете этим делом?

Тоже интересно про масштабирование. Если микросервисов штук 300 и в каждом 2-3 секрета

Зарегистрируйтесь на Хабре, чтобы оставить комментарий