aws privateca issuer
v1.4.0
AWS Private CA는 사설 CA를 설정 및 관리하고 사설 인증서를 발급할 수 있는 AWS 서비스입니다.
cert-manager는 다양한 발급 소스에서 TLS 인증서의 관리 및 발급을 자동화하는 Kubernetes 추가 기능입니다. 인증서가 유효한지 확인하고 주기적으로 업데이트하며 만료되기 전 적절한 시기에 인증서 갱신을 시도합니다.
이 프로젝트는 AWS Private CA를 사용하여 인증서 요청을 승인하는 cert-manager에 대한 애드온(https://cert-manager.io/docs/configuration/external/ 참조) 역할을 합니다.
먼저 cert-manager를 설치합니다(https://cert-manager.io/docs/installation/kubernetes/).
그런 다음 Helm을 사용하여 AWS PCA Issuer를 설치합니다.
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-name기본값 파일에서 차트 구성을 확인할 수 있습니다.
AWS PCA 발급자는 버전 1.3.0부터 ARM을 지원합니다.
AWS PCA 발급자는 기본 브랜치의 각 커밋에 해당하는 버전이 포함된 테스트 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 발급자는 서명하기 전에 CertificateRequests에 승인된 조건이 설정될 때까지 기다립니다. 이전 버전의 cert-manager(v1.3 이전)를 사용하는 경우 발급자 배포에 명령줄 플래그 -disable-approved-check 제공하여 이 검사를 비활성화할 수 있습니다.
AWSPCA 발급자는 기본적으로 kubernetes API 서버에 대한 요청 속도를 초당 5개의 쿼리로 제한합니다. API 우선순위 및 공정성을 구현한 최신 버전의 Kubernetes에는 이는 필요하지 않습니다. 최신 버전의 Kubernetes를 사용하는 경우 발급자 배포에 명령줄 플래그 -disable-client-side-rate-limiting 제공하여 이 클라이언트 측 속도 제한을 비활성화할 수 있습니다.
인증을 위해 KIAM을 사용하는 경우 이 플러그인은 KIAM v4.0에서 테스트되었습니다. IRSA도 테스트되고 지원됩니다.
사용자가 전달된 AWS Creds를 사용하여 Kubernetes 비밀을 정의할 수 있도록 플러그인에 코딩한 사용자 지정 AWS 인증 방법이 있습니다. 예는 여기에 있습니다. 사용자는 해당 파일을 자신의 자격 증명과 함께 적용한 다음 플러그인을 실행할 때 발행자 CRD에서 비밀을 참조합니다(예: 여기).
AWS PCA(Private Certificate Authority) 발급자 플러그인은 다음과 같은 통합 및 사용 사례를 지원합니다.
cert-manager 1.4+ 및 해당 Kubernetes 버전과 통합됩니다.
인증 방법:
AWS 사설 CA 기능:
번역 코드는 여기에서 찾을 수 있습니다.
Cert-Manager 인증서에 설정된 UsageTypes에 따라 다양한 AWS PCA 템플릿이 사용됩니다. 이 표는 IssueCertificate 요청 시 사용할 템플릿으로 UsageTypes가 변환되는 방식을 보여줍니다.
| Cert-Manager 사용 유형 | AWS PCA 템플릿 ARN |
|---|---|
| 코드서명 | acm-pca:::템플릿/CodeSigningCertificate/V1 |
| 클라이언트인증 | acm-pca:::템플릿/EndEntityClientAuthCertificate/V1 |
| 서버인증 | acm-pca:::템플릿/EndEntityServerAuthCertificate/V1 |
| OCSP서명 | acm-pca:::템플릿/OCSPSigningCertificate/V1 |
| 클라이언트인증, 서버인증 | acm-pca:::템플릿/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 실행하기 전에 다음을 수행해야 합니다.
- 컴퓨터에 다음 도구가 있어야 합니다.
- (선택 사항) K8 비밀을 통해 인증을 테스트하려면 AWS IAM 사용자가 필요합니다. export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name> 통해 이미 기존 사용자를 테스트에 제공할 수 있습니다. 이 IAM 사용자에는 구성에 나열된 정책을 따르는 정책이 연결되어 있어야 합니다. 이 사용자는 K8 비밀을 통해 플러그인에서 인증을 테스트하는 데 사용됩니다.
- us-east-1에서 BPA가 비활성화된 S3 버킷. 버킷을 생성한 후 export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- CLI를 통해 IAM 정책을 통해 다음 작업을 최소한으로 허용하는 AWS 자격 증명을 터미널에 로드해야 합니다.
acm-pca:* : 테스트를 위해 적절한 API를 통해 사설 CA를 생성하고 삭제할 수 있습니다.iam:CreatePolicy , iam:CreateUser 및 iam:AttachUserPolicy 권한이 필요합니다.iam:CreateAccessKey 및 iam:DeleteAccessKey : 이를 통해 K8 비밀을 통한 인증이 작동하는지 확인하는 데 사용할 액세스 키를 생성하고 삭제할 수 있습니다. 사용자가 $PLUGIN_USER_NAME_OVERRIDE를 통해 설정된 경우s3: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 실행합니다. make cluster && make install-eks-webhook && make kind-cluster-delete ). 그렇지 않으면 .well-known/openid-configuration 파일이 없다는 오류가 표시될 수 있습니다. 이러한 명령을 실행하면 S3 버킷을 부트스트랩하여 OIDC 공급자를 생성할 수 있습니다. OIDC 공급자의 공급자 URL을 $OIDC_S3_BUCKET_NAME.s3.us-east-1.amazonaws.com/cluster/my-oidc-cluster 로 설정합니다. 대상을 sts.amazonaws.com 으로 설정합니다.
- 방금 생성된 IAM OIDC 공급자와 신뢰 관계를 맺고 있는 IAM 역할입니다. 이 역할에 대한 인라인 정책은 테스트 실행 중에 생성되므로 특정 CA로 범위를 지정할 수 없다는 점을 제외하고 구성에서 가져올 수 있습니다. 이 역할은 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/
교차 계정 발급자가 작동하는지 테스트하려면 다음이 필요합니다.
- CLI를 통해 엔드투엔드 테스트를 시작하는 호출자를 신뢰하는 역할이 있는 별도의 AWS 계정, 해당 역할에는 다음 권한이 있는 정책이 필요합니다.
acm-pca:* : 이는 테스트에서 다른 계정으로 사설 CA를 생성할 수 있도록 하기 위한 것입니다.ram:GetResourceShareAssociations , ram:CreateResourceShare 및 ram:DeleteResourceShare : 이를 통해 소스(발신자) 계정과 공유할 수 있는 CA를 생성할 수 있습니다.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 폴더 내의 다른 파일은 주로 자주 업데이트할 필요가 없는 유틸리티입니다.
새로운 AWS Load Balancer 컨트롤러를 사용하여 Amazon EKS에서 엔드투엔드 TLS 암호화 설정 블로그에 설명된 워크플로가 작동하는지 테스트합니다. 테스트를 실행하려면: 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로 인코딩되어야 합니다.
생성된 CertificateRequest에 이벤트가 표시되지 않으면 승인 확인을 지원하지 않는 이전 버전의 cert-manager를 사용하고 있을 가능성이 높습니다. 발급자 배포 시 승인 확인을 비활성화합니다.
도움이 필요하면 다음 장소를 순서대로 고려하십시오.
우리는 커뮤니티 기여와 끌어오기 요청을 환영합니다.
문제 보고, 개발 환경 설정 및 코드 제출 방법에 대한 자세한 내용은 기여 가이드를 참조하세요.
우리는 Amazon 오픈 소스 행동 강령을 준수합니다.
