Utilize IAM Roles for AWS Authentication when running inside of AWS

[mfacenet]

Is this a bug report or feature request?

• Feature Request

What should the feature do:
Utilize IAM Roles to authenticate to the AWS API when available.

What is use case behind this feature:
As a engineer, I don't wish to concern myself with the details of securing/rotating security credentials, as such, I want to utilize IAM Roles assigned to the nodes that crossplane is executing on to authenticate to the AWS services. Optionally I want to utilize kube2iam or kiam to manage which IAM role crossplane has access to.

Environment:
Crossplane running inside of a Kubernetes cluster on AWS, with or without kube2iam/kiam installed

[mfacenet]

Of note, I believe the standard configuration flow for AWS Clients is as follows:
IniConfig
EnvFallback
IAMFallback
Fail

[prasek]

@hasheddan is this fixed now with #126?

[hasheddan]

@prasek yep! Thanks for flagging 👍

[martin-ducar-gd]

A question here. I see the Service account role support has been added that means you can annotate service account and that will in the end bring ENV variables like AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE to provider-aws pod which it will use to authenticate to AWS API. Which is good but it becomes really hard to do cross account assume. EKS webidentity is somehow fixed to that account where the EKS cluster lives. And unless I'm mistaken, assuming role in another account is done as 2 step process (Call assume role of another account inside pod explicitly leveraging existing Service account role). What was I think instead meant here is with tools like kube2iam kiam its much more simpler to cross account assume without POD even knowing it all you do is add annotation to pod: iam.amazonaws.com/role: "arn:aws:iam::<account_id>:role/<role_name>" and if your kiam or kube2iam is able to assume that role it will give it to provider-aws via redirecting metadata call to 169.254.169.254... all it needs to do is use aws-sdk with fallback to ec2rolecreds. What I think is missing really is a way to annotate a provider-aws pod with proper annotation as that is done via ControllerConfig and Provider abstractions. Is there any way to define that now or really its needed to modify the crossplane logic?

[hasheddan]

What I think is missing really is a way to annotate a provider-aws pod with proper annotation as that is done via ControllerConfig and Provider abstractions.

@martin-ducar-gd as you mention, this can be done with a ControllerConfig (previously you could only annotate the Deployment and ServiceAccount, but the coming v1.1.0 Crossplane release will update ControllerConfig to have a spec.metadata field to annotate the Pod. You can see an example of doing that here.). I believe tou can fall back on default credential chain in provider-aws with source: None in your AWS ProviderConfig. Does this fit your use case?

[martin-ducar-gd]

Oh great that seems like exactly what might enable that functionality. Thank you @hasheddan