The credentials are going to be the hardest thing I believe. I think it depends on how “ready to roll” you want to make it ahead of time.
Path 1 - users do it all
The admin creates the user account and grants the access for add-model to the new user. The register command that’s printed out is sent to the user.
They then need instructions are how to add the credentials after they register and set the password. It might be reference to a valid credentials yaml file that can be linked to the user (email a link, or attach, or …)
The user then does juju add-credential -f ...
This is best if there’s unique credentials generated per user.
Path 2 - admins do all the hard work
The other way to go is have the admins create the account, grant it access, then use the register command themselves to create an initial password for the new user account and load the credentials.
The end user is then given a valid juju login $ip:$port -c $localname -u $username. As long as they have the password they will get a local cache of info setup and the account can be setup with as much detail/info as needed.
This doesn’t apply for us since we have a “candid” server which has the users password already set in our local ActiveDirectory.
The controller “superuser”(s) just do “juju grant USER@corporate login” + "juju grant USER@corporate add-model
(The juju grant add-model isn’t documented btw )
… so, the superuser never gets a register command to send to a user (as this post initially described).
The process so far is something like this:
Admin bootstrap the candid enabled controller.
Admin does “juju grant USER@corporate login”
Admin does “juju grant USER@corporate add-model” (For those users that has cloud-logins/credentials)
Now, USER, needs to get relevant information which currently is:
USER runs “juju” once to get .local/share/juju/ directory with defaults.
copy a controller.yaml + cloud.yaml
… or USER must modify/replace controller.yaml + clouds.yaml
USER must run "juju switch somecontroller
USER must run “juju add credential” corresponding to the contents of the yamls.
USER must run “juju update-credentials …” (a few times if vsphere due to getting logged out all the time)
USER must run “juju set-default-credentials …”
USER must run “juju login -u USER@corporate”
USER must run “juju switch somemodel” (or juju status will throw ERROR)
… I might miss out on some detail above, but consider a new user of juju. The experience so far from 2 experienced devopsers in our company needed significant assistance from me and @xinyuem to get going with this. I hope we are doing something horribly wrong.
This feels like something I need to try out… but wasn’t this related to the discussion with @hallback above (requires root privilegues for the user at the client side)?
No root required. We’ve done work in 2.6 for login so it should just work to get the user setup. They’ll be asked to trust the cert fingerprint during their first login but that’s it.
On the controller, the admin issued: “juju grant USER@corporate superuser”
Then, I tried to login:
$ juju login 10.104.129.39:17070 -c iuba-vmware -u USER@corporate
Controller “10.104.129.39:17070” presented a CA cert that could not be verified.
CA fingerprint: [4D:1C:43:1E:E0:04:8F:19:90:5B:1B:38:0D:9F:C6:D4:60:F8:A2:B9:51:1C:06:9E:66:97:41:59:AB:3B:5E:2F]
Trust remote controller? (y/N): y
ERROR cannot log into “10.104.129.39:17070”: invalid entity name or password (unauthorized access)
Hmm, it failed. Lets try with admin.
$ juju login 10.104.129.39:17070 -c iuba-vmware -u admin
Controller “10.104.129.39:17070” presented a CA cert that could not be verified.
CA fingerprint: [4D:1C:43:1E:E0:04:8F:19:90:5B:1B:38:0D:9F:C6:D4:60:F8:A2:B9:51:1C:06:9E:66:97:41:59:AB:3B:5E:2F]
Trust remote controller? (y/N): y
Enter password:
Welcome, admin. You are now logged into “iuba-vmware”.
There are 2 models available. Use “juju switch” to select
one of them:
juju switch controller
juju switch default
So, now I logout admin:
juju logout
… and try login with the “normal” username (USER@corporate)
Hmm, the thing I think that is missing is getting the user account know in candid first. I wonder if @martin-hilton has any insight into that first load of the user into Candid and how we might seed that. Does the user need to make sure to first log into the Candid login webpage? Then would the juju login succeed?
In the first example it doesn’t look like it is getting as far as talking to candid. It looks like juju (It doesn’t look like JIMM if it’s at 17070) is rejecting the user based on not knowing the username. If you repeat with --debug we might be able to tell where it’s getting stuck.
I think the gap is that you have to make sure that the controller knows about the user so we have to run the add-user command with the @corporate (or actually external?) user.
So I think the steps need to be
juju add-user USER@external
juju grant USER@external login
juju grant USER@external add-model
We’ll have a go on this. @xinyuem is also looking at this.
A question on the “external” - what is this for really as we are in fact using “scania” here instead of “corporate” and/or “external” as I just changed that to make it more general to the post. What would the meaning of that name be?
I’m not sure. I think at one point in time the idea was there would be users across federated identity back ends so you’d have rick@canonical and bob@scania. In the end, I think the @external is currently tied as a hint that “user that’s not a native juju account” so that we’re not trying to match the username/password in the local juju db but lean on the external identity provider.
Ah, I see. I think we’ll stay with “scania” then since this might go with your original thought and after all, we are authenticating with our company ActiveDirectory LDAP backend.
The add-user command is for dealing only with local users on a controller.
As @rick_h mentioned above, the idea was always for an identity provider to managage external users, like the @scania part. I had always thought that the part after the @ would be configurable. Not sure if that bit was implemented.
So, the way to get the USER@scania would be to use candid.
Yes, we do have candid, integrated with AD, but the thing is that we’re trying to figure out how to get the juju client setup for a controller without having to copy or edit yaml files.
The ‘juju register’ way was super, but that doesnt work with candid.
Yes. The login command hits an unauthenticated endpoint to initiate download of the server CA Cert, and the user is authenticated. There are some caveats…
the machine needs to have routability to the controller
the controller should be configured with candid
the special user everyone@external should be granted login and add-model permissions
The external user should not be added as per @rick_h’s post above. everyone@external is a special user that exists for the purpose of configuring general perissions until Juju gets proper RBAC security.
NOTE: you should use “@external” here even though you use “@scania” for the candid entries because “everyone@external” is a hard-coded string in Juju just now.
Note! The client must not provide the username at login (will error) but instead uses the URL login provided by candid for that.
Login succeed!
After this, adding cloud and credentials is needed to be able to “juju add-model” as:
juju add-cloud … (cloud name must match exactly the cloud name in the controller)
juju add-credential …
juju update-credentials …
juju add-model …
… etc
As a follow up question: Is there a way to extract the cloud names from the controller since that is important for the subsequent “juju add-cloud” to make sure the name of the clouds are exactly the same on the client as on the controller…
This is by all means great news for the simplified way of adding in new users to a/the Juju infrastructure. Thanx alot for taking us there!
