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.
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.
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
.
Cory, thanks for your insights here…
two questions
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?
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
I am not an AWS expert, but I am wondering what is involved to allow role based authentication from JUJU. From my account which I intended to deploy the juju from, I can run aws cli or python code to access AWS api.
Besides not asking the credential, what else is involved to make role based auth to work?
I am willing to tackle this problem if someone can point me to the code path in juju that deals with aws authentication.
Ming
@fuming188 - I’ve been slamming my head on this as well and if you would be able to cover ground here, it would be amazing. @tlm @jamesbeedy @jameinel @hmlanigan should be your best contacts on this topic.
I guess even if the juju bootstrap runs from an ec2 with privileged role, it still need to create a controller ec2 and grant it the same access. I believe most of the aws api call are issued from the controller. So the starting ec2 not only need ec2 and S3 access, it also need aim access. Wonder if people will be comfortable with that.
Thanks for the questions. I believe what you are chasing is now possible thanks to some work the Juju team did last year.
Check out the post I wrote on how to try it here: Using AWS Instance Profiles With Juju 2.9
We haven’t received a great deal of feedback on this new feature so please if you have any we would love to hear.
tlm