Вопрос или проблема
Мы недавно внедрили Sigstore для подписи наших бинарных артефактов, используя подход без ключей. Этот фреймворк позволяет использовать токен OIDC, предоставленный кластером EKS (https://docs.sigstore.dev/certificate_authority/oidc-in-fulcio/#kubernetes), с установленными следующими данными (в случае k8s)
{
"kubernetes.io": {
"namespace": "default",
"pod": {
"name": "oidc-test",
"uid": "49ad3572-b3dd-43a6-8d77-5858d3660275"
},
"serviceaccount": {
"name": "default",
"uid": "f5720c1d-e152-4356-a897-11b07aff165d"
}
}
}
Подписание (https://docs.sigstore.dev/cosign/signing/signing_with_blobs/) и проверка (https://docs.sigstore.dev/cosign/verifying/verify/) объектов работают как ожидается.
CLI cosign (https://github.com/sigstore/cosign), который мы используем в процессе для обоих, требует следующую информацию во время стадии проверки.
Ниже приведено из cosign verify-blob --help
--certificate-identity='':
Идентификатор, ожидаемый в действительном сертификате Fulcio. Допустимые значения включают адреса электронной почты, DNS-имена, IP
адреса и URI. Должен быть установлен либо --certificate-identity, либо --certificate-identity-regexp для беспроводного
потока.
--certificate-oidc-issuer="":
OIDC-эмитент, ожидаемый в действительном сертификате Fulcio, например, https://token.actions.githubusercontent.com или
https://oauth2.sigstore.dev/auth. Должен быть установлен либо --certificate-oidc-issuer, либо --certificate-oidc-issuer-regexp для беспроводного потока.
Вопрос, можем ли мы раскрыть ID кластера EKS, наш OIDC-эмитент и имя нашей нагрузки k8s, т.е. имя нашей учетной записи службы в кластере EKS, содержащей токен OIDC, публике?
Хотя Rekor хранит информацию в доступном для общего пользования, только для чтения журнале, во время подписания мы хотим проверить, нормально ли открывать эту информацию на этапе проверки?
Ответ или решение
Безопасность и раскрытие информации при использовании Cosign и Sigstore
При использовании Sigstore для подписания бинарных артефактов с применением подхода без ключей (keyless), необходимо учитывать аспекты безопасности, связанные с раскрытием информации о вашей инфраструктуре. В вашем вопросе поднимается важная тема: можно ли открыто публиковать идентификатор вашего кластера EKS, идентификатор OIDC и имя рабочей нагрузки (service account) в кластере Kubernetes.
1. Понимание процессов подписания и верификации
Cosign, являясь инструментом для работы с подписью артефактов, использует OIDC-токен, предоставляемый вашим кластером Kubernetes. Этот токен содержит определенные компоненты, такие как идентификаторы и информация об учетной записи сервиса, которые требуются для успешного подписания и верификации.
Стандартные параметры, такие как --certificate-identity и --certificate-oidc-issuer, требуют предоставления информации о том, каков ожидаемый формат сертификата Fulcio. Таким образом, ваша инфраструктура должна быть четко настроена для эффективной работы с сигнатурами и их подтверждением.
2. Риски раскрытия идентификаторов
Теперь давайте рассмотрим возможные риски, связанные с открытым раскрытием:
-
Уязвимость к атакам: Раскрытие идентификаторов вашего кластера или учетной записи сервиса может предоставить злоумышленникам информацию, которая облегчит атаки на вашу инфраструктуру. Например, зная имя сервисной учетной записи, злоумышленники могут попытаться получить доступ к ресурсам, к которым эта учетная запись имеет доступ.
-
Читабельность логов Rekor: Хотя логи в Rekor действительно открыты и содержат информацию о действиях, таких как подписи, лучше не делать утверждения, которые могли бы помочь злоумышленникам в целях разведки.
3. Рекомендации по безопасности
Чтобы минимизировать риски, рекомендуется следующее:
-
Ограничьте область видимости: Не публикуйте идентификаторы вашего EKS, OIDC и имена рабочей нагрузки без необходимости. Применяйте принципы минимальной необходимой доступности.
-
Используйте регулярное обновление: Если существует необходимость раскрытия идентификаторов, убедитесь, что они регулярно обновляются и вся старая информация удаляется.
-
Мониторинг и аудит: Внедряйте решения для мониторинга использования этих идентификаторов и проводите регулярные аудиты прав доступа к вашим Kubernetes ресурсам.
4. Заключение
В целом, раскрытие идентификаторов вашего EKS, OIDC и сервисной учетной записи в открытом доступе не рекомендуется из-за потенциальных угроз безопасности. Всегда лучше оставаться на стороне осторожности, ограничивая доступ к критически важной информации, и обеспечивать, чтобы любые данные, которые могут быть раскрыты, были минимально необходимыми для выполнения заданной функции без ущерба для безопасности.
Учитывая, что во время проверки (verify) скрытие этой информации может повлиять на возможности верификации, вы можете использовать альтернативные методы, такие как анонимизация или хеширование, для обеспечения безопасности без ущерба для функциональности.