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:

juju autoload-credentials

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!

Comments