How can I juju add-credential with certificate credentials for lxd?

When I’m trying to add a certificate for authentication to my LXD cloud with “juju add-credential”

It’s unclear to me how I can supply certificates for client, key and server via the interface. Its prompting me, but pasting the content of my client.crt, server.crt and client.key into the terminal is really not a friendly way.

So far, the only way I have managed to add a certificate is by manually editing the ~/.local/share/juju/credentials.yaml to get this to work. That is a horrible experience and also very error prone.

I realize I can create a separate yaml file and supply it as an argument. But, the interactive session should really let me supply a file-name argument to simplify this process… if it doesn’t already exist…

@hmlanigan @ppasotti @tmihoc - I’m following up on this as I constantly slam into this.

Hey Erik,

I know you are familiar with the file method using -f. Currently this is the only way to supply such information. I have had a look at expanding the credentials support in Juju to have filename certificate arguments. It’s possible and we have a few roads with which we could implement this. I will bring this up in the team to get this work considered.

Please let us know if there is other information we should consider as part of this.

Ta tlm

1 Like

Hello, yes I’m aware of the -f, but have you tried the interactive way yet?

Its error all over and gives no hint as how to even complete the process.

It doesn’t say what or how I’m supposed to enter the certificates and is a bad UX just generally.

Since LXD would otherwise be such a nice experience, but this is a major hurdle.

Hey Eric,

I had a look around and we had a small fix that I was able to give to Juju to handle this input better. Essentially our input mechanism doesn’t handle multi line values at the moment but because we considered the input a secret we were unable to have it as file name input.

I have made a change that will allow you to enter these values as file names for Juju to read in.

Bug: Bug #1988239 “Interactive credential file support.” : Bugs : juju


This change should come with our next 2.9* release.


1 Like

The current process I use for a client when adding a new LXD host (cloud) to an existing controller is as follows and will automatically add certificates to the client “credentials.yaml”:

Adding a lxd cloud to an existing controller

Temporarily have admin enable password authentication on the remote lxd if you have disabled it as part of a production grade installation (this is not needed if lxd-admin already has added the client.crt) in the lxc remote (lxc config trust add client.crt), but this is the easy-but-not-as-secure-version:

 lxc config set core.trust_password 12345678

On the client, add the new LXD host as a remote:

lxc remote add new-cloud

Make sure you are “admin” on the controller (my-controller).

juju switch my-controller

juju whoami
Controller:  my-controller
Model:       controller
User:        admin

Now, lets add this new (lxd) cloud to the (juju) controller which the client is already aware of since we added it as a lxd remote.

juju add-cloud new-cloud my-controller

On the juju client (make sure you have run lxc locally first, such that your ~/snap/lxd/common/config/client.crt file is available. This is needed by juju autoload-credentials which will take care of adding the credentials to the client and controller.

juju autoload-credentials

Select 3 if this is a new client as we want to add both locally and in the controller. Select the proper credential and give it a name, lets say “cred00”

Test that admin can create a new model (the first model must also be told explicitly to use your new credential:

juju add-model my-model new-cloud --credential cred00

When this works, users needs now also be granted possibility to use the cloud or it wont show up in the “juju clouds” and no models can be deployed to it by users that are not granted add-model access.

juju grant-cloud erik-lonroth add-model my-cloud

If you logout and repeat the process for a second user, the new cloud should be available to it aswell.

juju logout
juju login -u erik
juju clouds

$ juju clouds
Only clouds with registered credentials are shown.
There are more clouds, use --all to see them.

Clouds available on the controller:
Cloud           Regions  Default  Type
iceberg         1        default  lxd  
new-cloud       1        default  lxd  

Clouds available on the client:
Cloud      Regions  Default    Type  Credentials  Source    Description
aws        19       us-east-1  ec2   2            public    Amazon Web Services
dwellir    1        default    lxd   1            built-in  LXD Cluster
google     20       us-east1   gce   1            public    Google Cloud Platform
iceberg    1        default    lxd   1            local     LXD Container Hypervisor
localhost  1        localhost  lxd   1            built-in  LXD Container Hypervisor
new-cloud  1        default    lxd   1            built-in  LXD Cluster

Have admin lock down the lxd-host again so it will not be open with an easy password!

lxc config unset core.trust_password

I’m not sure this process can be simplified, but I think this is the best I’ve been able to produce so far.

Hey Erik,

Thanks for the feedback. My first instinct when reading this is that for many large lxd clusters and having and organisation wide auth with a proper pki system setup would be the gold standard. I have never done this with LXD but it does look to be supported. Something to possibly think about to get all of your clusters under the same root signer and have all of your ops people with a single signed client certificate that is trusted for the by the clusters automatically that they can access.

Your process looks correct however you can avoid the steps of adding the lxd cluster to the local lxd client and just add the new cloud and credentials through Juju bypassing the lxd client if you don’t intend to use it.

The RBAC that we currently have in Juju around adding new clouds is something we are aware of for areas of improvement. There are currently discussions ongoing around a better revised RBAC implementation that is more uniform and adaptable across the suite of products that Canonical offers.

Let me know if I can elaborate on any of the above more or offer some more docs. Currently Dora and myself are working on credentials docs for Juju so I will deferentially take what we have discussed here and integrate it.

1 Like

Thanx @tlm

I agree on you here, but the assumption that a common setup of juju is a large enterprise where setting up a PKI infrastructure (pulling along with it more opex) is not ideal.

Most companies (or teams) are only a few members and doesn’t fit the description.

It has taken me years to arrive to this description… I still don’t feel comfortable and my experience is that this (credential management) is causing alot of headaches to people trying to learn how juju works.

1 Like

Thanks @erik-lonroth,

I’ll take all of this information as input’s to our discussions around credentials.

Please feel free to give us some feedback on the next 2.9 release around interactive certificate credentials.

1 Like

I would, if I knew what to look for, test etc.

Why won’t you demo this for the community instead which would give you alot more input?

We can set you up in either EU or American time.

@hmlanigan @tmihoc @ppasotti

1 Like

Hej Erik,

I recently stumbled upon a need to add a juju-driver which piggy backs on the gitlab-runner mechanism… and I wanted to have it use the gitlab-runner linux user

I’ve created the gitlab-runner added it to the lxd user group… I can register the user on my hosts original controller and grant is SOME permission… but when I go to

juju add-model test

it complains there’s no credential… so I attempt to autoload the credential and it appears to get stuck in a loop

juju autoload-credentials
This operation can be applied to both a copy on this client and to the one on a controller.
Do you want to add a credential to:
    1. client only (--client)
    2. controller "localhost-localhost" only (--controller localhost-localhost)
    3. both (--client --controller localhost-localhost)
Enter your choice, or type Q|q to quit: 3

Looking for cloud and credential information on local client...

Looking for cloud information on controller "localhost-localhost"...

1. LXD credential "localhost" (new)
Select a credential to save by number, or type Q to quit: 1

Select the cloud it belongs to, or type Q to quit [localhost]: 

Saved LXD credential "localhost" to cloud localhost locally

1. LXD credential "localhost" (existing, will overwrite)
Select a credential to save by number, or type Q to quit: 1

Select the cloud it belongs to, or type Q to quit [localhost]: 

Saved LXD credential "localhost" to cloud localhost locally

1. LXD credential "localhost" (existing, will overwrite)
Select a credential to save by number, or type Q to quit: 1

Select the cloud it belongs to, or type Q to quit [localhost]: localhost

Saved LXD credential "localhost" to cloud localhost locally

1. LXD credential "localhost" (existing, will overwrite)
Select a credential to save by number, or type Q to quit: 1

Select the cloud it belongs to, or type Q to quit [localhost]: 

any thoughts there? Seems I might wipe the machine and give up… just install LXD and Juju using the gitlab-runner user and move on… but ideally I want to be able to share the controller with two linux users easily…

EDIT: okay I think I got it working… this looping of selecting things OR QUIT … is not super clear at first… I ended up quitting and it looks like it’s working now

1 Like