Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Служба Azure Kubernetes (AKS) хранит конфиденциальные данные, такие как секреты Kubernetes, в etcd, распределенном хранилище данных ключ-значение, используемом Kubernetes. Для повышения безопасности и соответствия требованиям AKS поддерживает шифрование неактивных секретов Kubernetes с помощью поставщика службы управления ключами Kubernetes (KMS), интегрированного с Azure Key Vault.
В этой статье описываются основные понятия, модели шифрования и параметры управления ключами, доступные для защиты неактивных секретов Kubernetes в AKS.
Понимание шифрования данных в состоянии покоя
Шифрование неактивных данных защищает данные при его хранении на диске. Без шифрования злоумышленник, получающий доступ к базовому хранилищу, может потенциально считывать конфиденциальные данные, такие как секреты Kubernetes.
AKS обеспечивает шифрование секретов Kubernetes, хранящихся в etcd:
| Уровень | Description |
|---|---|
| Шифрование платформы Azure | Служба хранилища Azure автоматически шифрует все неактивных данных с помощью 256-разрядного шифрования AES. Это шифрование всегда включено и прозрачно для пользователей. |
| Шифрование поставщика KMS | Необязательный слой, который шифрует секреты Kubernetes перед записью в etcd с помощью ключей, хранящихся в Azure Key Vault. |
Дополнительные сведения о возможностях шифрования данных Azure при хранении см. в Шифрование данных Azure в состоянии покоя и Моделях шифрования Azure.
Поставщик KMS для шифрования данных
Поставщик KMS Kubernetes — это механизм, который позволяет шифровать секреты Kubernetes в состоянии покоя с использованием внешней системы управления ключами. AKS интегрируется с Azure Key Vault, чтобы обеспечить эту возможность, обеспечивая контроль над ключами шифрования при сохранении преимуществ безопасности управляемой службы Kubernetes.
Как работает шифрование KMS
При включении KMS для кластера AKS:
- Создание секрета: при создании секрета сервер API Kubernetes отправляет секретные данные в подключаемый модуль поставщика KMS.
- Шифрование. Подключаемый модуль KMS шифрует секретные данные с помощью ключа шифрования данных (DEK), который сам шифруется с помощью ключа шифрования ключей (KEK), хранящегося в Azure Key Vault.
- Хранилище: зашифрованный секрет хранится в etcd.
- Извлечение секрета. При чтении секрета подключаемый модуль KMS расшифровывает DEK с помощью KEK из Azure Key Vault, а затем использует DEK для расшифровки секретных данных.
Этот подход шифрования конверта обеспечивает как преимущества безопасности, так и производительности. DEK обрабатывает частые операции шифрования локально, а KEK в Azure Key Vault обеспечивает безопасность аппаратной системы управления ключами.
Параметры управления ключами
AKS предлагает два варианта управления ключами для шифрования KMS:
Управляемые платформой ключи (PMK)
С помощью ключей, управляемых платформой, AKS автоматически управляет ключами шифрования.
- AKS создает ключи шифрования и управляет ими.
- Поворот ключа автоматически обрабатывается платформой.
- Дополнительная настройка или настройка хранилища ключей не требуется.
Когда следует использовать управляемые платформой ключи:
- Вам нужна самая простая настройка с минимальной конфигурацией.
- У вас нет конкретных нормативных требований, которые предписывают ключи, управляемые клиентом.
- Вы хотите автоматическую смену ключей без ручного вмешательства.
Ключи, управляемые клиентом (CMK)
С помощью ключей, управляемых клиентом, у вас есть полный контроль над ключами шифрования:
- Вы создаете и управляете собственными ключами Azure Key Vault и ключами шифрования.
- Вы управляете расписаниями и политикой ротации ключей.
Когда следует использовать ключи, управляемые клиентом:
- У вас есть нормативные требования или требования соответствия требованиям, которые предписывают ключи, управляемые клиентом.
- Необходимо управлять жизненным циклом ключей, включая графики ротации и версии ключей.
- Для всех ключевых операций требуется журнал аудита.
Параметры сетевого доступа к хранилищу ключей
При использовании ключей, управляемых клиентом, можно настроить сетевой доступ для Azure Key Vault:
| Доступ к сети | Description | Сценарий использования |
|---|---|---|
| Public | Хранилище ключей доступно через общедоступный Интернет с проверкой подлинности. | Среды разработки, упрощенная настройка |
| Private | Доступ к общедоступной сети для хранилища ключей отключен. AKS получает доступ к хранилищу ключей через исключение брандмауэра доверенных служб. | Рабочие среды, улучшенная безопасность |
Сравнение параметров ключа шифрования
| Функция | Ключи, управляемые платформой | Управляемые клиентом ключи (общедоступная версия) | Управляемые клиентом ключи (частные) |
|---|---|---|---|
| Владение ключом | Управление корпорацией Майкрософт | Клиент управляет | Клиент управляет |
| Смена клавиш | Автоматически | Настраиваемый пользователь | Настраиваемый пользователь |
| Создание хранилища ключей | Автоматически | Создает клиент | Создает клиент |
| Сетевая изоляция | N/A | нет | Да |
Требования
- Для нового шифрования KMS с ключами, управляемыми платформой, или ключами, управляемыми клиентом, с автоматическим поворотом ключей требуется Kubernetes версии 1.33 или более поздней.
- Новое шифрование KMS с ключами, управляемыми платформой, или ключами, управляемыми клиентом, с автоматической ротацией ключей поддерживается только в кластерах AKS, где управляемая идентичность используется как идентификатор кластера.
Ограничения
- Нет понижения. После включения нового интерфейса шифрования KMS невозможно отключить эту функцию.
- Удаление ключей: удаление ключа шифрования или хранилища ключей делает секреты неустранимыми.
- Доступ к частной конечной точке: доступ к хранилищу ключей с помощью приватного канала или конечной точки пока не поддерживается. Для хранилищ закрытых ключей используйте исключение брандмауэра доверенных служб.