Несколько секретов в kubernetes

Рекомендации по управлению 3 или 4 секретами для одного развертывания Kubernetes.

У нас есть развертывание, в котором некоторые секреты повторяются во всех пространствах имен, а другие зависят от среды.

Мы пытаемся выбрать между одним секретным файлом и изменением только тех, которые должны быть, ИЛИ запускаем 2+ секрета, один из которых — foo-dev-secrets, а другой — foo-universal-secrets.

Мы не можем найти никаких примеров того, что делать в таких случаях, точнее, как управлять этими секретами, мы знаем, что у вас может быть только «один секрет на том», но, честно говоря, мы не уверены, что это значит.

Не стесняйтесь отвечать, как будто мы глупые дети. ^_^


kubernetes kubernetes-namespace
person TallOrderDev    schedule 27.03.2018    source источник

Ответы (1)


arrow_upward
3
arrow_downward

запуск 2+ секретов, один из которых - foo-dev-secrets, а другой - foo-universal-secrets

На ваш взгляд, хорошо построенная политика RBAC гарантирует, что только учетные записи с правильными разрешениями смогут читать секреты, если они разложены, что было бы (конечно) намного сложнее, если бы все они были объединены в один. ведро "все секреты"

мы знаем, что у вас может быть только «один секрет на том», но, честно говоря, мы не уверены, что это значит.

Тогда вы в хорошей компании, потому что я тоже не знаю, что это значит :-D Если вы имеете в виду, что есть глобальные секреты, но секреты разработчиков называются так же, но более конкретно, я думаю docker -v потерпит, что:

containers:
- name: foo
  volumeMounts:
  - name: global-secrets
    mountPoint: /run/secrets/global
    readOnly: true
  - name: foo-secret-override
    mountPoint: /run/secrets/global/no-really
    readOnly: true

... с тем недостатком, что ваши volumes: и volumeMounts: станут довольно болтливыми

Тем не менее, я бы поспорил, что более общее и менее запутанное решение состоит в том, чтобы смонтировать их как одноранговые узлы, а затем выполнить эквивалент приложения find /run/secrets/ -not -type d, чтобы поглотить их все:

  volumeMounts:
  - name: global-secrets
    mountPoint: /run/secrets/0-global
    readOnly: true
  - name: foo-secrets
    mountPoint: /run/secrets/1-foo
    readOnly: true

Или, если возможно, пусть приложение считывает путь из переменной окружения или ConfigMap-ed ситуации, что означает, что их можно спроецировать как одноранговые (по-прежнему), но указать приложению, какое из двух значений оно должно использовать.

Конечно, дьявол кроется в деталях, поэтому не стесняйтесь вмешаться, если вы можете поделиться более подробной информацией о препятствиях, с которыми вы сталкиваетесь.

person mdaniel    schedule 27.03.2018
comment
Большое спасибо, это помогло, я все еще потерян, но это указывает мне правильное направление для исследований! Спасибо, отпишусь, если найду что-то особенное. Проголосовал и помечен как ответ! - person TallOrderDev; 27.03.2018