Support for IAM roles for service account setup in workload cluster

[michaelbeaumont]

/kind feature

Describe the solution you'd like
This provider should take care of the steps outlined in the AWS docs for setting up IRSA.

Suggesting:

spec:
  associateOIDCProvider: true

and the issuer URL and OIDC provider ARN (or even the entire trust policy?) can be made available on status so that users can create the roles they require.

Anything else you would like to add:

• Previous discussion around AWSManagedMachinePool creation with @randomvariable where the node role can be made less permissive using IRSA

[michaelbeaumont]

/assign

[michaelbeaumont]

For each service account + IAM policies combination that a user needs, they have to create an IAM role and add a trust policy document, which is unique to the service account + provider ARN/URL.

Some ideas discussed by @richardcase and I on how to make using the created OIDC provider easier:

• Provide the user with a trust policy document in a ConfigMap, containing a placeholder for the service account (envsubst compatible)
• Have the ARN/URL in the status and add a command to clusterawsadm to facilitate things:
  • it could output the trust policy doc, given a cluster and a service account namespace/name
  • it could output CFN to create an IAM role, given policies to attach (similar to what eksctl does as seen in the linked docs)

[MarcusNoble]

@michaelbeaumont I'd like to try and tackle this if noone else already is.

Is your suggestion for associateOIDCProvider to go on AWSCluster/AWSManagedCluster or on AWSControlPlane/AWSManagedControlPlane?

My current understanding of whats needed:

• Add reconcile logic for creating/updating/deleting the IAM Identity Provider
• Associate it with the cluster
• Update status to include the details needed for the trust policy
• Create a configmap in the associated workload cluster with a boilerplate trust policy
• Update the IAM permissions used for CAPA to be able to perform the above actions

For non-EKS clusters, would we want to install amazon-eks-pod-identity-webhook as part of cluster-api or leave it for the users to handle?

I also think a separate ticket should be raised to cover making the node permissions less permissive rather than doing it as part of this work.

[michaelbeaumont]

@MarcusNoble I'd already started work on it (neglected to add /lifecycle active, apologies) but you're welcome to finish/collaborate on it!

• My opinion is that since the setup for non-EKS clusters is so much more involved, it may be worth putting it off
• Agree about node permissions, that was just for reference

[michaelbeaumont]

/lifecycle active

[MarcusNoble]

@MarcusNoble I'd already started work on it (neglected to add /lifecycle active, apologies) but you're welcome to finish/collaborate on it!

Sure thing! Anything specific you'd like me to focus on? Looking at what you have so far it doesn't look like there's too much more that's needed.
It looks like it still needs:

• deleteReconcile
• Create a boilerplate trust policy
• Update IAM permissions for CAPA (I haven't actually checked if the current already cover whats needed)

• My opinion is that since the setup for non-EKS clusters is so much more involved, it may be worth putting it off

I wasn't aware it was so much more involved. I agree, best to focus on EKS for now (as it's generally expected to be available) and non-EKS can be handled in the future if there is a call for it.