aws privateca issuer
v1.4.0
Частный центр сертификации AWS — это сервис AWS, который позволяет настраивать частные центры сертификации и управлять ими, а также выдавать частные сертификаты.
cert-manager — это надстройка Kubernetes для автоматизации управления и выдачи сертификатов TLS из различных источников. Он будет гарантировать, что сертификаты действительны, периодически обновляться и пытаться обновить сертификаты в подходящее время до истечения срока их действия.
Этот проект действует как дополнение (см. https://cert-manager.io/docs/configuration/external/) к cert-manager, которое подписывает запросы сертификатов с помощью частного центра сертификации AWS.
Сначала установите cert-manager (https://cert-manager.io/docs/installation/kubernetes/).
Затем установите AWS PCA Issuer с помощью Helm:
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-nameВы можете проверить конфигурацию диаграммы в файле значений по умолчанию.
AWS PCA Issuer поддерживает ARM, начиная с версии 1.3.0.
AWS PCA Issuer поддерживает тестовый ECR, содержащий версии, соответствующие каждому коммиту в основной ветке. Доступ к этим изображениям можно получить, установив для репозитория изображений значение public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test и для тега изображения значение latest . Пример того, как это делается, показан ниже:
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-name
--set image.repository=public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test
--set image.tag=latest На данный момент единственными настраиваемыми параметрами является доступ к AWS. Таким образом, вы можете использовать AWS_REGION , AWS_ACCESS_KEY_ID или AWS_SECRET_ACCESS_KEY .
Альтернативно, вы можете указать произвольные секреты для доступа и секретных ключей с помощью полей accessKeyIDSelector и secretAccessKeySelector в манифестах кластера и/или издателя.
Доступ к AWS также можно настроить с помощью роли экземпляра EC2 или [IAM-ролей для сервисных учетных записей] (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). ).
Минимальная политика использования эмитента с полномочиями будет выглядеть следующим образом:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "awspcaissuer",
"Action": [
"acm-pca:DescribeCertificateAuthority",
"acm-pca:GetCertificate",
"acm-pca:IssueCertificate"
],
"Effect": "Allow",
"Resource": "arn:aws:acm-pca:<region>:<account_id>:certificate-authority/<resource_id>"
}
]
}
Этот оператор предоставляет два пользовательских ресурса, которые вы можете использовать.
Примеры можно найти в каталогах примеров и образцов.
Это обычный эмитент с пространством имен, который можно использовать в качестве ссылки в ваших сертификатах CR.
Этот CR идентичен AWSPCAIssuer. Единственное отличие состоит в том, что он не имеет пространства имен и на него можно ссылаться откуда угодно.
Аннотация cert-manager.io/cluster-issuer не может использоваться для указания на AWSPCAClusterIssuer . Вместо этого используйте cert-manager.io/issuer: . Пожалуйста, ознакомьтесь с этим выпуском для получения дополнительной информации.
Эмитент AWSPCA будет ждать, пока в запросе сертификата будет установлено утвержденное условие, прежде чем подписывать. Если вы используете более старую версию cert-manager (до версии 1.3), вы можете отключить эту проверку, указав флаг командной строки -disable-approved-check для развертывания эмитента.
Эмитент AWSPCA по умолчанию ограничит скорость запросов к серверу API Kubernetes до 5 запросов в секунду. В этом нет необходимости для новых версий Kubernetes, в которых реализованы API Priority и Fairness. Если вы используете более новую версию Kubernetes, вы можете отключить это ограничение скорости на стороне клиента, указав флаг командной строки -disable-client-side-rate-limiting для развертывания эмитента.
Обратите внимание: если вы используете KIAM для аутентификации, этот плагин был протестирован на KIAM v4.0. IRSA также протестирован и поддерживается.
Мы запрограммировали в нашем плагине специальный метод аутентификации AWS, который позволяет пользователю определить секрет Kubernetes с помощью переданных учетных данных AWS, пример здесь. Пользователь применяет этот файл со своими учетными данными, а затем ссылается на секрет в своем CRD эмитента при запуске плагина, пример здесь.
Плагин эмитента AWS Private Certificate Authority (PCA) поддерживает следующие интеграции и варианты использования:
Интеграция с cert-manager 1.4+ и соответствующими версиями Kubernetes.
Методы аутентификации:
Возможности частного центра сертификации AWS:
Код для перевода можно найти здесь.
В зависимости от того, какие UsageTypes установлены в сертификате Cert-Manager, будут использоваться разные шаблоны AWS PCA. В этой таблице показано, как UsageTypes преобразуются в какой шаблон использовать при выполнении запроса IssueCertificate:
| Типы использования Cert-Manager | Шаблон AWS PCA ARN |
|---|---|
| Подписание кода | acm-pca:::template/CodeSigningCertificate/V1 |
| КлиентАутентификация | acm-pca:::template/EndEntityClientAuthCertificate/V1 |
| Сервераутентификация | acm-pca:::template/EndEntityServerAuthCertificate/V1 |
| Подписание OCSPS | acm-pca:::template/OCSPsigningCertificate/V1 |
| КлиентАутентификация, СерверАутентификация | acm-pca:::template/EndEntityCertificate/V1 |
| Все остальное | acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 |
Запуск make test запустит написанный модульный тест.
Если вы столкнулись с такой проблемой, как
/home/linuxbrew/.linuxbrew/Cellar/go/1.17/libexec/src/net/cgo_linux.go:13:8: no such package located
Это можно исправить с помощью
brew install gcc@5
ПРИМЕЧАНИЕ. За выполнение этих тестов будет взиматься плата с вашего аккаунта AWS .
Запуск make e2etest возьмет текущие артефакты кода и преобразует их в образ Docker, который будет работать в кластере типа и гарантировать, что текущая версия кода по-прежнему работает с поддерживаемыми рабочими процессами.
Самый простой способ запустить тест — использовать следующие цели make: make cluster && make install-eks-webhook && make e2etest
make cluster make cluster создаст на вашем компьютере своего рода кластер, на котором установлен Cert-Manager, а также плагин aws-pca-issuer (используя HEAD текущей ветки)
Перед запуском make cluster нам нужно будет сделать следующее:
- Имейте на своей машине следующие инструменты:
- (Необязательно) Вам понадобится пользователь AWS IAM для проверки аутентификации с помощью секретов K8. Вы можете предоставить уже существующего пользователя для участия в тесте с помощью export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name> . К этому пользователю IAM должна быть прикреплена политика, следующая за политикой, указанной в разделе «Конфигурация». Этот пользователь будет использоваться для проверки аутентификации в плагине с помощью секретов K8.
- Ведро S3 с отключенным BPA на востоке США-1. После создания сегмента запустите export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- Вам потребуются учетные данные AWS, загруженные в ваш терминал, которые через CLI как минимум разрешают следующие действия с помощью политики IAM:
acm-pca:* : это сделано для того, чтобы частные центры сертификации можно было создавать и удалять с помощью соответствующих API для тестирования.iam:CreatePolicy , iam:CreateUser и iam:AttachUserPolicyiam:CreateAccessKey и iam:DeleteAccessKey : это позволяет нам создавать и удалять ключи доступа, которые будут использоваться для проверки работоспособности аутентификации с помощью секретов K8. Если пользователь был установлен через $PLUGIN_USER_NAME_OVERRIDEs3:PutObject и s3::PutObjectAcl их можно ограничить до корзины s3, созданной выше. - Поставщик AWS IAM OIDC. Прежде чем создавать поставщика OIDC, установите временное значение для $OIDC_IAM_ROLE ( export OIDC_IAM_ROLE=arn:aws:iam::000000000000:role/oidc-kind-cluster-role и запустите make cluster && make install-eks-webhook && make kind-cluster-delete ). Это необходимо сделать, иначе вы можете увидеть ошибку с сообщением об отсутствии файла .well-known/openid-configuration. Выполнение этих команд помогает загрузить корзину S3, чтобы можно было создать поставщика OIDC. Установите URL-адрес поставщика OIDC: $OIDC_S3_BUCKET_NAME.s3.us-east-1.amazonaws.com/cluster/my-oidc-cluster . Установите аудиторию sts.amazonaws.com .
— Роль IAM, имеющая доверительные отношения с только что созданным поставщиком IAM OIDC. Встроенную политику для этой роли можно получить из конфигурации, за исключением того, что вы не можете ограничить ее конкретным центром сертификации, поскольку они будут созданы во время тестового запуска. Эта роль будет использоваться для проверки аутентификации в плагине через IRSA. Доверительные отношения должны выглядеть примерно так:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "${OIDC_ARN}"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"${OIDC_URL}:sub": "system:serviceaccount:aws-privateca-issuer:aws-privateca-issuer-sa"
}
}
}
]
}
После создания этой роли запустите export OIDC_IAM_ROLE=<IAM role arn you created above>
- make cluster воссоздать кластер со всеми соответствующими установленными переменными среды
- make install-eks-webhook установит вебхук в кластер такого типа, который позволит использовать IRSA
- make e2etest выполнит сквозное тестирование для кластера типа, созданного с помощью make cluster .
- После локального обновления кода контроллера простой способ повторно развернуть новый код контроллера и повторно запустить сквозной тест — запустить:: make upgrade-local && make e2etest
Запуск IRSA для работы с Kind был во многом вдохновлен следующим блогом: https://reece.tech/posts/oidc-k8s-to-aws/
Если вы также хотите проверить работу эмитентов перекрестных учетных записей, вам потребуется:
— Отдельная учетная запись AWS с ролью, которая доверяет вызывающему абоненту, который запускает сквозное тестирование через CLI. Для этой роли потребуется политика со следующими разрешениями.
acm-pca:* : это значит, что тест может создать частный центр сертификации для другой учетной записи.ram:GetResourceShareAssociations , ram:CreateResourceShare и ram:DeleteResourceShare : они позволяют создать центр сертификации, который можно использовать совместно с учетной записью источника (вызывающего абонента).export PLUGIN_CROSS_ACCOUNT_ROLE=<name of the role you created above> . Если вы этого не сделаете, вы увидите сообщение о том, что тестирование между учетными записями пропущено из-за того, что эта переменная среды не установлена.Вскоре эти тесты должны запускаться автоматически для каждого PR, но на данный момент каждый PR будет иметь основного сотрудника проекта, который будет запускать тесты вручную, чтобы гарантировать отсутствие регрессий в поддерживаемых рабочих процессах.
Тест довольно прост: он берет набор «шаблонов эмитента» (базовое имя для aws-pca-issuer, а также AWSIssuerSpec) и набор «шаблонов сертификатов» (базовое имя для типа сертификата, а также спецификация сертификата). Затем тесты возьмут каждую спецификацию сертификата и применят ее к каждой спецификации эмитента. Тест гарантирует, что все эмитенты, созданные на основе спецификаций эмитента, достигнут состояния готовности, а также гарантирует, что каждый сертификат, выданный эмитентом, достигнет состояния готовности. Проверено, что эмитенты с разными сертификатами работают как для эмитентов кластера, так и для эмитентов пространства имен.
По большей части сквозное обновление будет заключаться в обновлении этих «спецификаций эмитента» и «спецификаций сертификатов», которые находятся в e2e/e2e_test.go. Если тесту требуется дополнительное обновление, основная логика теста также встроена в e2e/e2e_test.go. Остальные файлы в папке e2e — это в основном утилиты, которые не требуют частого обновления.
Проверьте, работает ли рабочий процесс, изложенный в блоге «Настройка сквозного шифрования TLS в Amazon EKS с помощью нового контроллера балансировки нагрузки AWS». Чтобы запустить тест: make cluster && make install-eks-webhook && make blog-test
Тест, который скачивает последнюю версию через Helm, проверяет, что плагин установлен правильно, имеет правильную версию, а затем корректно удаляется. Чтобы запустить тест, make cluster && make install-eks-webhook && make helm-test
Проверьте секрет с помощью учетных данных AWS: значения AWS_ACCESS_KEY_ID и AWS_SECRET_ACCESS_KEY должны быть закодированы в формате Base64.
Если сгенерированный запрос сертификата не отображает никаких событий, весьма вероятно, что вы используете более старую версию диспетчера сертификатов, которая не поддерживает проверку утверждения. Отключите проверку утверждения при развертывании эмитента.
Для получения помощи, пожалуйста, рассмотрите следующие места (по порядку):
Мы приветствуем вклад сообщества и запросы на включение.
Дополнительную информацию о том, как сообщать о проблемах, настраивать среду разработки и отправлять код, см. в нашем руководстве по участию.
Мы придерживаемся Кодекса поведения Amazon с открытым исходным кодом.
