Секреты Kubernetes и сервисные аккаунты

Я работаю с кубернетами последние 6 месяцев, и мы развернули несколько сервисов.

Мы собираемся развернуть еще один, который хранит зашифрованные данные и помещает ключи в KMS. Для этого требуются две служебные учетные записи, одна для данных и одна для ключей.

Доступ к данным должен быть проверен. Поскольку доступ к этим данным очень конфиденциальный, мы неохотно помещаем обе учетные записи служб в пространство имен, как если бы они были скомпрометированы каким-либо образом, злоумышленник может получить доступ к данным и ключам без их аудита.

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

Это ужасно, так как требует, чтобы этот ключ был доверен одному человеку, и ограничивает масштабируемость. К счастью, объем этой услуги будет очень низким.

Кто-нибудь еще сталкивался с такой же проблемой? Как ты это решил?

ваше здоровье

Требования

  • Ни один человек не имеет доступа к обоим ключам (хранилищу данных и KMS).

gcloud kubernetes google-cloud-kms kubernetes-secrets
person Mark    schedule 23.07.2018    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Доступ к данным должен быть проверен.

Если вы включите журнал аудита, каждый вызов API, выполняемый через эту службу аккаунт будет зарегистрирован. Это может не помочь вам, если ваша служба никогда не вызывается через API, но, учитывая, что у вас есть учетная запись службы, похоже, что это так.

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

Вы можете использовать для этого Vault. Если вы храните секрет в хранилище, вы можете использовать что-то вроде this, чтобы передать переменную среды вниз в модуль в качестве переменной среды автоматически. Это немного сложнее, чем ваш процесс, но гораздо безопаснее.

Вы также можете использовать Vault вместе с Google Cloud KMS, что подробно описано в этой статье < / а>

person jaxxstorm    schedule 23.07.2018
comment
Аудит включен, но нам не помогает то, что они загрузили хранилище данных и ключи и теперь могут расшифровать всю базу данных. - person Mark; 23.07.2018
comment
Я посмотрю на хранилище и посмотрю, удовлетворяет ли оно требованиям, спасибо. - person Mark; 23.07.2018

arrow_upward
0
arrow_downward

То, что вы описываете, довольно распространено - использование ключа / учетной записи службы / удостоверения в секретах Kubernetes для доступа к внешнему хранилищу секретов.

Меня немного смущает концепция двойного ключа - что вы получаете, имея ключ как в секретах, так и в модуле? Если секреты скомпрометированы, то etcd скомпрометирован, и у вас возникнут большие проблемы. Вместо этого я бы посоветовал вам сосредоточиться на блокировке секретов, использовании журналов аудита и упрощении смены ключа в случае компрометации.

Несколько моментов, которые следует учитывать:

  • Если вы в основном используете Kubernetes, рассмотрите возможность хранения (зашифрованных) секретов в секретах Kubernetes. .
  • Если вы храните секреты централизованно вне Kubernetes, как вы описываете, подумайте об использовании только одного секрета Kubernetes - вы получите журналы аудита Kubernetes для доступа к секрету (см. Рекомендуемые audit-policy) и журналы аудита Cloud KMS для использования ключа.
person Maya Kaczorowski    schedule 23.07.2018
comment
Возможно, я неправильно описал проблему, мы храним учетные записи служб в секрете, а не в модулях, git или чем-то еще. Проблема в том, что любой, кто получает доступ к пространству имен, может читать секреты и получать доступ к хранилищу данных и KMS, минуя нашу регистрацию аудита. Итак, мы добавили конечную точку API, чтобы второй ключ можно было разместить в модуле, сохранив его только в локальной памяти. - person Mark; 23.07.2018
comment
Понятно. Журнал аудита Kubernetes обычно записывает запросы к этому секрету. Если злоумышленник может получить доступ к секретам (не через входную дверь), вы правы, что он не будет регистрироваться в журнале аудита. - person Maya Kaczorowski; 25.07.2018