[Feature Request]: Assume role per Issuer

[EnriqueLop]

Describe why this change is needed

Currently, this project cannot assume different IAM roles based on the Issuer configuration. This limitation makes it challenging to use AWS PCA instances stored in multiple AWS accounts, as there is no built-in mechanism to define an assumable role per Issuer.

In multi-account setups, organizations may have AWS PCA instances residing in different AWS accounts while their Kubernetes clusters exist in a separate centralized account. However, since AWS PCA Issuers do not currently support assuming a role per Issuer, it is impossible to authenticate against different AWS accounts dynamically.

Allowing an Issuer to specify an IAM role to assume would enable seamless integration with AWS PCA across different accounts. This would be particularly useful for scenarios where:

• Each AWS PCA instance is hosted in a separate AWS account.
• The cluster account needs to authenticate against these AWS PCA instances dynamically.
• A specific role assumption strategy is required per Issuer.

Describe solutions and alternatives considered (optional)

Introduce an option in the Issuer configuration that allows specifying an IAM role to assume, similar to how native cert-manager supports role assumption.

This feature would align AWS PCA Cert Manager with other Kubernetes authentication patterns that leverage IAM role assumption. It would also improve security by following the principle of least privilege while enabling better multi-account AWS PCA management.

---
apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
  name: issuer-A
spec:
  arn: awspca-account-A
  role: role-account-A
---
apiVersion: awspca.cert-manager.io/v1beta1
kind: AWSPCAClusterIssuer
metadata:
  name: issuer-B
spec:
  arn: awspca-account-B
  role: role-account-B

With this configuration, on the ClusterIssuer reconciliation it will assume a role based on the value of role.

cert-manager, external-secrets and external-dns do support assume role.

Is there anything else you would like to add?

I see that some test uses assume role but I can not find how to use it in production environment.

[ndbhat]

Hi @EnriqueLop, Thank you for submitting this feature request. We will review the request and get back to you.

[bmsiegel]

Hi @EnriqueLop, our issuer supports cross account CA issuance. Have you considered this for your usecase? https://docs.aws.amazon.com/privateca/latest/userguide/pca-ram.html

[EnriqueLop]

Hi @bmsiegel. Yeah, we can manage it that way.

I think that this tool could manage both functionalities the same way as cert-manager does. I will try to make a POC with aws-privateca-issuer.

[EnriqueLop]

Here is a quick idea:

#374

Each config will define if a role should be assumed or not and it will be used based on NamespaceName authentication map.

[paragor]

@bmsiegel please take a look at #427

When Subordinate AWS PCA is shared via AWS RAM, there is no way to issue a certificate with isCA: true, because there is no template for it https://docs.aws.amazon.com/privateca/latest/userguide/UsingTemplates.html

What do you think?

[bmsiegel]

I think this is a symptom of the another issue where customers can't set the template themselves (because then you can set the template properly to an api passthrough template). I'm still not sure this is something that we need. Please let me know if I'm missing something though.

Relevant issue: #220

[nickperry]

My organisation really needs this chained AssumeRole feature.

@bmsiegel the problem with PCA RAM sharing is It is too limiting.

We have a requirement to issue pathlen0 subordinate certs from a PCA in another account. It is critical for our use-case that x509 name constraints from the Certificate spec are applied to these certs. That is not possible today via RAM, because RAM is constrained to a subset of PCA templates (and PCA RAM shares do not support customer managed permissions). The only subordinate template that RAM supports is SubordinateCACertificate_PathLen0/V1. We need to use SubordinateCACertificate_PathLen0_CSRPassthrough/V1 or SubordinateCACertificate_PathLen0_APIPassthrough/V1 so we can pass through our name constraints (which are more tightly scoped than those of the parent PCA) and have PCA honour them.

Being able to use a chained AssumeRole in pca-privateca-issuer would let us assume a role in the PCA issuer account, giving us access to the templates we need and sidestepping the limitations imposed on RAM shares.

Once we have AssumeRole, we just need another feature to which you alluded - the ability to select the correct template (#220).

See also #428

[bmsiegel]

Thanks for the insight, I agree that this would be the only path forward.