AWS PCA shared cannot generate certificate about aws-privateca-issuer HOT 17 CLOSED

If someone else find this issue it can be solved by adding the following annotation to ingress:
cert-manager.io/usages: "server auth,client auth"

from aws-privateca-issuer.

After looking in the pca.go it appears that for you to request the EndEntityCertificate/V1 and meet the condition is by adding under the spec.usages section of the certificate yaml, -server auth along with -client auth!

Let me know if that helps. If you want support for more templates between shared resources that would be an AWS support request rather than a request here.

Regards,
Tony

from aws-privateca-issuer.

You are right, this issue was on my side. I initially crated IRSA role for cert-manager because I thought the cert-manager SA needs IRSA because PCA is only a plugin which is called on behalf of cert-manager. But then switched to IRSA for ServiceAccount aws-privateca-issuer and annotated it which cannot work. No I corrected the trust policy of the rule with the correct SA! Sorry for that.

from aws-privateca-issuer.

No problem at all! Thank you for reaching out to Amazon AWS. Please reopen if you have any issues or questions.

from aws-privateca-issuer.

Thanks for the information.

Please refer to the following in the README: https://github.com/cert-manager/aws-privateca-issuer#mapping-cert-manager-usage-types-to-aws-pca-template-arns.

AWS Private CA has certificate templates (specified by templates ARNs) that are used when issuing certificates. Only a subset of these certificate templates are supported in cross-account issuance via RAM. The list of RAM-supported certificate templates is available on the RAM console. You chose AWSRAMDefaultPermissionCertificateAuthority - this corresponds to the following certificate template acm-pca:::template/EndEntityCertificate/V1. According to the chart in the README, you'll have to set your Usage Types to ClientAuth, ServerAuth to get this plugin to issue acm-pca:::template/EndEntityCertificate/V1 certificates. Please give that a go, and let me know.

from aws-privateca-issuer.

If someone else find this issue it can be solved by adding the following annotation to ingress: cert-manager.io/usages: "server auth,client auth"

Thank you so much!

This needs to be documented...

from aws-privateca-issuer.

if there is a way to define the template within the Certificate yaml file it would be enough to bypass this.. Or embed the template arn within the plugin

from aws-privateca-issuer.

And how I can do that in automated way with Ingress?

from aws-privateca-issuer.

@clsonel-endava This blog demonstrates how to issue private certificates which are issued with default EndEntityCertificate/V1 template and can be used with cross account CAs: https://aws.amazon.com/blogs/security/tls-enabled-kubernetes-clusters-with-acm-private-ca-and-amazon-eks-2/

Does it help?

from aws-privateca-issuer.

Where is the automation? That means I will need to take care of generating the certificate. cert-manager has an automate mechanism for ingresses to request certificates, without creating effectively the certificate resource in K8S, and I think that is something that need to be used, not going back to do things manually

from aws-privateca-issuer.

I used the Helm chart version "0.1.2" a minute ago which belongs to "image: ghcr.io/jniebuhr/aws-pca-issuer:v0.3.1" which should have fixed the IRSA issue but still get the following error:
{"level":"error","ts":1636296506.7310438,"logger":"controller-runtime.manager.controller.awspcaclusterissuer","msg":"Reconciler error","reconciler group":"awspca.cert-manager.io","reconciler kind":"AWSPCAClusterIssuer","name":"tf-eks-root-ca","namespace":"","error":"operation error STS: GetCallerIdentity, failed to sign request: failed to retrieve credentials: failed to retrieve credentials, operation error STS: AssumeRoleWithWebIdentity, https response error StatusCode: 403, RequestID: ca384609-e126-4d6c-bcf0-6e8b0bd230cb, api error AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:132\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:302\nsigs.k8s.io/controller-runtime/pkg/internal/controller.

The SA is properly annotated an the role policy is correct as well! pod has projected volume with credentials. What goes wrong here?

from aws-privateca-issuer.

Hello! Thank you for raising this issue with us. While I work to reproduce your issue, could you please provide some more information such as your role policy? At first glance it looks like you have a permissions error in your policy, because the API returned AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity

from aws-privateca-issuer.

Having a similar issue with using v1.0.0 when upgrading from v0.1.0. Using aws-privateca-issuer with AWS PCA shared from another account via RAM and IRSA. The error generated:

{"level":"error","ts":1639487465.7000027,"logger":"controllers.CertificateRequest","msg":"failed to request certificate from PCA","certificaterequest":"***HIDDEN***","error":", https response error StatusCode: 400, RequestID: ***HIDDEN***, api error AccessDeniedException: User: arn:aws:sts::***HIDDEN***:assumed-role/***HIDDEN***/***HIDDEN*** is not authorized to perform: acm-pca:IssueCertificate on resource: arn:aws:acm-pca:eu-west-2:***HIDDEN***:certificate-authority/***HIDDEN*** because no resource-based policy allows the acm-pca:IssueCertificate action","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\t/go/pkg/mod/github.com/go-logr/[email protected]/zapr.go:132\ngithub.com/cert-manager/aws-privateca-issuer/pkg/controllers.(*CertificateRequestReconciler).Reconcile\n\t/workspace/pkg/controllers/certificaterequest_controller.go:171\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:298\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:253\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1.2\n\t/go/pkg/mod/sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:216\nk8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext.func1\n\t/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:185\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1\n\t/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:155\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil\n\t/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:156\nk8s.io/apimachinery/pkg/util/wait.JitterUntil\n\t/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:133\nk8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext\n\t/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:185\nk8s.io/apimachinery/pkg/util/wait.UntilWithContext\n\t/go/pkg/mod/k8s.io/[email protected]/pkg/util/wait/wait.go:99"}

The service account is correct:
Name: cert-manager-acm-issuer Namespace: cert-manager Labels: <none> Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::***HIDDEN***:role/***HIDDEN*** Image pull secrets: <none> Mountable secrets: cert-manager-acm-issuer-token-g8qzd Tokens: cert-manager-acm-issuer-token-g8qzd Events: <none>

The policy for the AWS role is correctly permissioned as in the configuration documentation.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "awspcaissuer", "Effect": "Allow", "Action": [ "acm-pca:ListTags", "acm-pca:ListPermissions", "acm-pca:IssueCertificate", "acm-pca:GetCertificateAuthorityCertificate", "acm-pca:GetCertificate", "acm-pca:DescribeCertificateAuthority" ], "Resource": "***HIDDEN***" } ] }

from aws-privateca-issuer.

Hello! Thank you for raising this issue with us. While I work to reproduce your issue, could you please provide some more information such as the policy you are using on your CA to share it CrossAccount and what template you are using to issue the certificate? At first glance it looks like you have a permissions error in your policy, because the API returned AccessDenied, or you may be using a template that is not supported in cross account.

Please see this for more information and let me know if that helps: https://docs.aws.amazon.com/acm-pca/latest/userguide/pca-rbp.html

from aws-privateca-issuer.

Hi, thanks for the prompt response. We using the sharing access via Organization option in RAM from the link above. The permissions we have config on the resource share is "AWSRAMDefaultPermissionCertificateAuthority" which has the below allowed actions:

acm-pca:IssueCertificate
acm-pca:DescribeCertificateAuthority
acm-pca:GetCertificate
acm-pca:GetCertificateAuthorityCertificate
acm-pca:ListPermissions
acm-pca:ListTags

The template we using to issue the certificate is the below:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: ServiceName
spec:
secretName: "{{ .Values.certificate.secretName }}"
commonName: "{{ .Values.certificate.dns.serviceName }}"
duration: {{ .Values.certificate.duration }}
renewBefore: {{ .Values.certificate.renewBefore }}
dnsNames:"{{ .Values.certificate.dns.serviceName }}"
issuerRef:
group: awspca.cert-manager.io
kind: AWSPCAClusterIssuer
name: ResourceShareName

from aws-privateca-issuer.

Thank you very much @divyansh-gupta , that was exactly what was missing from our certificate templates.

from aws-privateca-issuer.

If someone else find this issue it can be solved by adding the following annotation to ingress: cert-manager.io/usages: "server auth,client auth"

I spent an hour struggling with this after casually removing the "client auth" because "I only needed SSL certs". The fact that the cert was stored in a secret that survives Helm uninstall and was reused on Helm install, hid my mistake for a few days before catching me completely unaware at a time where I had forgotten the change.

from aws-privateca-issuer.