aws privateca issuer
v1.4.0
AWS Private CA é um serviço AWS que pode configurar e gerenciar CAs privadas, bem como emitir certificados privados.
cert-manager é um complemento do Kubernetes para automatizar o gerenciamento e a emissão de certificados TLS de várias fontes emissoras. Ele garantirá que os certificados sejam válidos, atualizados periodicamente e tentará renová-los em um momento apropriado antes de expirarem.
Este projeto atua como um complemento (consulte https://cert-manager.io/docs/configuration/external/) para o cert-manager que assina solicitações de certificado usando AWS Private CA.
Instale o cert-manager primeiro (https://cert-manager.io/docs/installation/kubernetes/).
Em seguida, instale o AWS PCA Issuer usando Helm:
helm repo add awspca https://cert-manager.github.io/aws-privateca-issuer
helm install awspca/aws-privateca-issuer --generate-nameVocê pode verificar a configuração do gráfico no arquivo de valores padrão.
AWS PCA Issuer oferece suporte a ARM a partir da versão 1.3.0
O AWS PCA Issuer mantém um ECR de teste que contém versões que correspondem a cada commit na ramificação principal. Essas imagens podem ser acessadas definindo o repositório de imagens como public.ecr.aws/cert-manager-aws-privateca-issuer/cert-manager-aws-privateca-issuer-test e a tag da imagem como latest . Um exemplo de como isso é feito é mostrado abaixo:
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 No momento, as únicas configurações configuráveis são o acesso à AWS. Então você pode usar AWS_REGION , AWS_ACCESS_KEY_ID ou AWS_SECRET_ACCESS_KEY .
Alternativamente, você pode fornecer segredos arbitrários para o acesso e chaves secretas com os campos accessKeyIDSelector e secretAccessKeySelector no clusterissuer e/ou manifestos do emissor.
O acesso à AWS também pode ser configurado usando uma função de instância EC2 ou [Funções IAM para contas de serviço] (https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html ).
Uma política mínima para usar o emissor com autoridade seria a seguinte:
{
"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>"
}
]
}
Este operador fornece dois recursos customizados que você pode usar.
Exemplos podem ser encontrados nos diretórios de exemplos e amostras.
Este é um emissor regular com namespace que pode ser usado como referência em seus CRs de certificado.
Este CR é idêntico ao AWSPCAIssuer. A única diferença é que não tem namespace e pode ser referenciado de qualquer lugar.
A anotação cert-manager.io/cluster-issuer não pode ser usada para apontar para um AWSPCAClusterIssuer . Em vez disso, use cert-manager.io/issuer: . Consulte este problema para obter mais informações.
O emissor AWSPCA aguardará que CertificateRequests tenha uma condição aprovada definida antes de assinar. Se estiver usando uma versão mais antiga do cert-manager (anterior à v1.3), você pode desabilitar essa verificação fornecendo o sinalizador de linha de comando -disable-approved-check para a implantação do emissor.
O emissor AWSPCA limitará a taxa de solicitações ao servidor API kubernetes para 5 consultas por segundo por padrão. Isso não é necessário para versões mais recentes do Kubernetes que implementaram API Priority and Fairness. Se estiver usando uma versão mais recente do Kubernetes, você pode desabilitar essa limitação de taxa do lado do cliente, fornecendo o sinalizador de linha de comando -disable-client-side-rate-limiting para a implantação do emissor.
Observe que se você estiver usando o KIAM para autenticação, este plugin foi testado no KIAM v4.0. IRSA também é testado e suportado.
Existe um método de autenticação AWS personalizado que codificamos em nosso plug-in que permite ao usuário definir um segredo do Kubernetes com AWS Creds passados, exemplo aqui. O usuário aplica esse arquivo com seus créditos e, em seguida, faz referência ao segredo em seu CRD do emissor ao executar o plugin, exemplo aqui.
O plug-in emissor da AWS Private Certificate Authority (PCA) oferece suporte às seguintes integrações e casos de uso:
Integração com cert-manager 1.4+ e versões correspondentes do Kubernetes.
Métodos de autenticação:
Recursos de CA privada da AWS:
O código para a tradução pode ser encontrado aqui.
Dependendo de quais UsageTypes estão definidos no certificado Cert-Manager, diferentes modelos AWS PCA serão usados. Esta tabela mostra como os UsageTypes estão sendo traduzidos em qual modelo usar ao fazer uma solicitação IssueCertificate:
| Tipo(s) de uso do Cert-Manager | ARN do modelo AWS PCA |
|---|---|
| Assinatura de código | acm-pca:::template/CodeSigningCertificate/V1 |
| Autenticação do Cliente | acm-pca:::template/EndEntityClientAuthCertificate/V1 |
| Autenticação do servidor | acm-pca:::template/EndEntityServerAuthCertificate/V1 |
| Assinatura OCSPS | acm-pca:::template/OCSPSigningCertificate/V1 |
| ClientAuth, ServerAuth | acm-pca:::template/EndEntityCertificate/V1 |
| Todo o resto | acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 |
Executar make test executará o teste de unidade escrito
Se você se deparar com um problema como
/home/linuxbrew/.linuxbrew/Cellar/go/1.17/libexec/src/net/cgo_linux.go:13:8: no such package located
Isso pode ser corrigido com um
brew install gcc@5
NOTA: A execução desses testes gerará cobranças em sua conta da AWS .
A execução de make e2etest pegará os artefatos de código atuais e os transformará em uma imagem Docker que será executada em um tipo de cluster e garantirá que a versão atual do código ainda funcione com os fluxos de trabalho suportados
A maneira mais fácil de executar o teste seria usar os seguintes alvos make: make cluster && make install-eks-webhook && make e2etest
make cluster seja executado make cluster criará um tipo de cluster em sua máquina que possui o Cert-Manager instalado, bem como o plugin aws-pca-issuer (usando o HEAD do branch atual)
Antes de executar make cluster precisaremos fazer o seguinte:
- Tenha em sua máquina as seguintes ferramentas:
- (Opcional) Você precisará de um usuário AWS IAM para testar a autenticação por meio de segredos K8. Você pode fornecer um usuário já existente no teste por meio de export PLUGIN_USER_NAME_OVERRIDE=<IAM User Name> . Este usuário do IAM deve ter uma política anexada que siga a política listada em Configuração. Este usuário será usado para testar a autenticação no plugin via segredos K8.
- Um bucket S3 com BPA desativado em us-east-1. Depois de criar o bucket, execute export OIDC_S3_BUCKET_NAME=<Name of bucket you just created>
- Você precisará de credenciais AWS carregadas em seu terminal que, via CLI, permitam minimamente as seguintes ações por meio de uma política IAM:
acm-pca:* : Isso ocorre para que CAs privadas possam ser criadas e excluídas por meio das APIs apropriadas para testeiam:CreatePolicy , iam:CreateUser e iam:AttachUserPolicyiam:CreateAccessKey e iam:DeleteAccessKey : Isso nos permite criar e excluir chaves de acesso a serem usadas para validar se a autenticação por meio de segredos K8 está funcional. Se o usuário foi definido via $PLUGIN_USER_NAME_OVERRIDEs3:PutObject e s3::PutObjectAcl podem ter o escopo definido até o bucket s3 que você criou acima - Um provedor AWS IAM OIDC. Antes de criar o provedor OIDC, defina um valor temporário para $OIDC_IAM_ROLE ( export OIDC_IAM_ROLE=arn:aws:iam::000000000000:role/oidc-kind-cluster-role e execute make cluster && make install-eks-webhook && make kind-cluster-delete ). Isso precisa ser feito, caso contrário você poderá ver um erro reclamando da ausência de um arquivo .well-known/openid-configuration. A execução desses comandos ajuda a inicializar o bucket S3 para que o provedor OIDC possa ser criado. Defina o URL do provedor OIDC como $OIDC_S3_BUCKET_NAME.s3.us-east-1.amazonaws.com/cluster/my-oidc-cluster . Defina o público como sts.amazonaws.com .
- Uma função do IAM que tem uma relação de confiança com o provedor IAM OIDC que acabou de ser criado. Uma política em linha para esta função pode ser obtida em Configuração, exceto que você não pode apontá-la para uma CA específica, pois elas serão criadas durante a execução do teste. Esta função será usada para testar a autenticação no plugin via IRSA. A relação de confiança deve ser algo como:
{
"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"
}
}
}
]
}
Depois de criar esta função, execute export OIDC_IAM_ROLE=<IAM role arn you created above>
- make cluster recriar o cluster com todas as variáveis de ambiente apropriadas definidas
- make install-eks-webhook instalará um webhook nesse tipo de cluster que permitirá o uso do IRSA
- make e2etest executará testes ponta a ponta no tipo cluster criado por meio de make cluster .
- Depois de atualizar o código do controlador localmente, uma maneira fácil de reimplantar o novo código do controlador e executar novamente o teste de ponta a ponta é executar:: make upgrade-local && make e2etest
Fazer com que o IRSA trabalhasse no Kind foi fortemente inspirado no seguinte blog: https://reece.tech/posts/oidc-k8s-to-aws/
Se quiser testar também se os emissores de contas cruzadas estão funcionando, você precisará de:
- Uma conta AWS separada que tenha uma função que confie no chamador que inicia o teste ponta a ponta por meio da CLI. A função precisará de uma política com as seguintes permissões
acm-pca:* : Isto é para que o teste possa criar uma CA privada é a outra contaram:GetResourceShareAssociations , ram:CreateResourceShare e ram:DeleteResourceShare : permitem a criação de uma CA que pode ser compartilhada com a conta de origem (chamador)export PLUGIN_CROSS_ACCOUNT_ROLE=<name of the role you created above> . Se você não fizer isso, verá uma mensagem sobre o teste entre contas sendo ignorado porque esta variável de ambiente não foi definida.Em breve esses testes deverão ser executados automaticamente em cada PR, mas por enquanto cada PR terá um colaborador principal do projeto para executar os testes manualmente para garantir que não haja regressões nos fluxos de trabalho suportados
O teste é bastante simples, eles usarão um conjunto de "modelos de emissor" (nome base para um emissor aws-pca, bem como um AWSIssuerSpec) e um conjunto de "modelos de certificado" (nome base para o tipo de certificado, bem como uma especificação de certificado). Os testes pegarão todas as especificações do certificado e as aplicarão a cada especificação do emissor. O teste garantirá que todos os emissores feitos a partir de especificações de emissor alcancem um estado pronto, bem como garantirá que cada certificado emitido por um emissor alcance um estado pronto. Verifica-se que os emissores com os diferentes certificados estão funcionando para emissores de cluster e de namespace.
Na maior parte, a atualização de ponta a ponta será a atualização dessas "especificações do emissor" e "especificações do certificado" que residem em e2e/e2e_test.go. Se o teste precisar de atualização além disso, a lógica central do teste também será incorporada em e2e/e2e_test.go. Os outros arquivos da pasta e2e são principalmente utilitários que não devem exigir atualizações frequentes
Teste para garantir que o fluxo de trabalho descrito no blog Configuração da criptografia TLS ponta a ponta no Amazon EKS com o novo AWS Load Balancer Controller esteja funcional. Para executar o teste: make cluster && make install-eks-webhook && make blog-test
Teste que baixa a versão mais recente via Helm, verifica se o plugin foi instalado corretamente, com a versão correta, e então é excluído corretamente. Para executar o teste make cluster && make install-eks-webhook && make helm-test
Verifique o segredo com as credenciais da AWS: os valores AWS_ACCESS_KEY_ID e AWS_SECRET_ACCESS_KEY devem ser codificados em base64.
Se o CertificateRequest gerado não mostrar eventos, é muito provável que você esteja usando uma versão mais antiga do cert-manager que não oferece suporte à verificação de aprovação. Desative a verificação de aprovação na implantação do emissor.
Para obter ajuda, considere os seguintes locais (em ordem):
Aceitamos contribuições da comunidade e solicitações pull.
Consulte nosso guia de contribuição para obter mais informações sobre como relatar problemas, configurar um ambiente de desenvolvimento e enviar código.
Aderimos ao Código de Conduta de Código Aberto da Amazon.
