AWS IAM users vs IAM roles as juju credentials?

I’m trying to figure out if its possible to use “IAM roles” as opposed to “IAM User” in the credentials.yaml

I’m not a AWS guru, so any help here would be helpful.

1 Like

I don’t believe this is possible.

Using a IAM roles in place of credentials assumes that your application is already running on an EC2 instance. The application then accesses the instance metadata API to obtain temporary credentials which it can use to talk to the AWS API.

The Juju client is generally run from outside of the cloud, not on an existing instance. It needs credentials that it can use to talk to the AWS API to bootstrap the initial controller instance, which will then continue to use those credentials to manage the rest of the instances on that cloud for all of the application units in its models.

In theory, you could start with a manually provisioned instance on the cloud upon which you install Juju, then manually query the instance metadata API for credentials and give those to Juju. However, I don’t think that Juju has any mechanism to handle needing to refresh the credentials by re-requesting them from the instance metadata API. Additionally, you would need to ensure that the the roles attached to the instance profile have enough permissions to allow Juju to do all of the administration that it does, and then anything else on that “jump host” instance would also be able to get access to those credentials just by querying the instance metadata API.

I also don’t really see much of a need for this with the Juju approach. The documented intention of the temporary instance credentials is to avoid needing to manually manage and communicate AWS credentials to various applications running in the cloud. However, in Juju’s case, typically the only application which needs any cloud credentials is the controller itself, which has those securely provided to it by the Juju client. And for the less common case where a particular application does need access to cloud credentials, the integrator charms provide a Juju-friendly way to manage those credentials and distribute them securely via relations. I would recommend, however, creating a specific IAM user for Juju and possibly a separate one for the integrator charm, if that is needed. Then, if you need to revoke those IAM users, you can always easily do so and update the controller using juju update-credential or the integrator and all related applications using juju config.

1 Like

Cory, thanks for your insights here…

two questions

  1. these integrator charms I am unfamiliar with… do you have a link to one for AWS or Azure ? So I can read up more when / why I would use that?

  2. if I have created an IAM Role… is there a way in juju to associate my Units/machines with that IAMRole programatically? or must I juju deploy .. and then after the fact somehow associate in AWS either via GUI or REST API… IAM Roles? Reason I ask is… I want to allow a certain Juju created EC2 instance access to an S3 bucket (or in theory anything that AWS provides via API like control of other services)…

Thanks for your explantation

1 Like

@jameinel @jamesbeedy @jnsgruk