route53.role can be omitted when using IRSA
#1487
Conversation
Signed-off-by: Max Brauer <[email protected]>
Signed-off-by: Max Brauer <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
cert-manager-prow
bot
added
dco-signoff: yes
✅ Deploy Preview for cert-manager-website ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
| @@ -184,6 +184,8 @@ spec: | |||
|
|
|||
| Note that, as mentioned above, the pod is using `arn:aws:iam::XXXXXXXXXXX:role/cert-manager` as a credentials source in Account X, but the `ClusterIssuer` ultimately assumes the `arn:aws:iam::YYYYYYYYYYYY:role/dns-manager` role to actually make changes in Route53 zones located in Account Y. | |||
|
|
|||
| **Note:** If you are using IRSA, omit `route53.role`. See [#4053](https://github.com/cert-manager/cert-manager/issues/4053). | |||
There was a problem hiding this comment.
Move this note to the EKS IAM Role for Service Accounts (IRSA) (below).
And update the example ClusterIssuer config in that IRSA section:
I don't know much about AWS and IRSA....can you explain (in the documentation note) why the role does not need to be supplied in this case.
The documentation for the Go Web SDK suggests that RoleARN is required
- https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/stscreds#AssumeRoleOptions
- https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/credentials/stscreds#WebIdentityRoleOptions
I'm interested to understand this because I'm currently working on the following update to the Route53 solver code in cert-manager:
There was a problem hiding this comment.
@wallrj thank you for reviewing this! I must admit that - just like you - I don't know much about AWS and IRSA. The reason I opened this PR was the positive feedback on the comment demonstrating "the solution".
For now I reckon the best course of action is to close this PR, because I am afraid I am unable to back it up beyond said comment.
It's the documentation cert-manager/cert-manager#4053 comment section is asking for.