I Hate Cloud Credentials
Working on multiple clouds can be a bear sometimes. Multiple clouds, multiple regions per cloud. If your team is organized it gets even better, with multiple accounts with different permissions. Did I use the right keys for the right account for this task?
In Juju 1.x, this was particularly painful. We made you stick everything in an
environments.yaml file, which is where we also had you stick other configuration options. For simple Hello World’s this was fine, but after a while of real world usage, it just became a mess, especially if you are constantly adding and removing credentials across clouds.
So for Juju 2.0 we’re going to be a lot smarter about this. First off, we can finally tell you what clouds we support, right from the CLI:
$ juju list-clouds CLOUD TYPE REGIONS aws ec2 us-east-1, us-west-1, us-west-2, eu-west-1, eu-central-1, ap-southeast-1, ap-southeast-2 ... aws-china ec2 cn-north-1 aws-gov ec2 us-gov-west-1 azure azure centralus, eastus, eastus2, northcentralus, southcentralus, westus, northeurope ... azure-china azure chinaeast, chinanorth cloudsigma cloudsigma hnl, mia, sjc, wdc, zrh google gce us-east1, us-central1, europe-west1, asia-east1 joyent joyent eu-ams-1, us-sw-1, us-east-1, us-east-2, us-east-3, us-west-1 lxd lxd localhost maas maas manual manual rackspace rackspace DFW, ORD, IAD, LON, SYD, HKG
We keep this up to date too, which means when a cloud provider adds a new region and it’s ready to go, you can just add it. Also if you’re keeping score, we’re supporting waaaaaay more clouds than we did before, giving you more choice on where to plop down infrastructure. Now you can just:
$ juju update-clouds Fetching latest public cloud list... done.
Find out about your favorite cloud with
juju show-cloud azure, or set a default,
juju set-default-region aws us-west-1. Or if you’ve got creds already just fire up a controller immediatelly and get modelling fast:
juju bootstrap exampledeploy aws/us-west-2.
Ok let’s add some creds to this cloud, we can do it a prompty way:
$ juju add-credential google credential name: testing select auth-type [jsonfile*, oauth2]: oauth2 client-id: example client-email: [email protected] private-key: **** project-id: project-test credentials added for cloud google
Okay so that handles just trying a cloud, not bad. Now to my favorite feature. If you’re a cloud person you probably have credentials for all sorts of clouds. These are given to you by your cloud provider, and of course, they’re all different. AWS gave me a
credentials.csv, Google has a json file, I have
.novarc for OpenStack, and so on. Of course in order to use the myriad of cloud tools I need I also have environment variables set all over the place aka
AWS_ACCESS_KEY_ID and so on. Juju will now just snag all that stuff and add it for you:
And follow the confirmation prompts, that’s all you need to get going on your existing clouds.
We also give you
juju add-credential and
juju remove-credential. Let’s have a look at
~/.local/share/juju/credentials.yaml so we can show you the structure of what a multi-cloud set up would look like:
credentials: aws: default-credential: peter default-region: us-west-2 peter: auth-type: access-key access-key: key secret-key: secret paul: auth-type: access-key access-key: key secret-key: secret homemaas: peter: auth-type: oauth1 maas-oauth: mass-oauth-key homestack: default-region: region-a peter: auth-type: userpass password: secret tenant-name: tenant username: user google: peter: auth-type: jsonfile file: path-to-json-file azure: peter: auth-type: userpass application-id: blah subscription-id: blah application-password: blah joyent: peter: auth-type: userpass sdc-user: blah sdc-key-id: blah private-key: blah (or private-key-path) algorithm: blah
So other than Peter having a personal cloud at home, everything here looks pretty normal and straightforward.
I’ve only really covered the initial user experience of our credentials work, but it’s by far the most boring part. The nice bit is that Juju also now allows full ACLs to the models allowing devops teams to set up infrastructure without giving up the keys to the entire castle to the wrong team. An example looks something like this:
juju add-user jorge --models mymodel --acl=write
But that is a topic for another day!