search

juju-solutions / layer-cwr

Layer for building the Juju Jenkins CI env
Other
2 stars 5 forks source link

No concept of 'ciuser' when using JAAS #103

Open jamesbeedy opened 7 years ago

jamesbeedy commented 7 years ago

This seems like a great path for those who self host controllers. Can we carve out another notch in the belt for those who are riding the ridge on the hosted controller?

jamesbeedy commented 7 years ago

How is the concept of a CI user provisioned via the hosted controller? I've had bouts with creating a dummy launchpad user just for this, but don't really know what other options may exist (still exploring).

ktsakalozos commented 7 years ago

Hi @jamesbeedy, you are expected to create a juju user on a controller as described here: https://jujucharms.com/docs/2.0/users-creating and then register this controller with the CI though the register-controller action. I am not sure I fully get your setup/constraints. Can you please describe the context you want to use the CI into?

kwmonroe commented 7 years ago

@jamesbeedy I think you're referring to the jaas controllers hosted by canonical, right? If so, it would be nice to support registering those controllers for the cwr charm to use, but I don't know how that would work at the moment. It may be as simple as specifying jimm.jujucharms.com as the token, but I haven't tried that yet.

A deeper dive is definitely needed here. Please lmk if you had something other than jaas in mind when you said 'hosted controller'.

Possibly related to https://github.com/juju-solutions/layer-cwr/issues/97.

jamesbeedy commented 7 years ago

@ktsakalozos @kwmonroe What I'm getting at here is that you don't always want to use your launchpad user for the ci user, or to login to your models from general utilities that other may end up inheriting the use/operation of. With JAAS, you are somewhat forced into this using the method of provisioning/registering accounts with Jenkins like the cwr charm does. I feel like one could get around this by creating a separate user(s) for common or utility purposes in launchpad. For example, I want Jenkins to authenticate against my models on the hosted controller to run actions on my charms via libjuju, I end up using my personal account to auth from Jenkins with. It doesn't feel right leaving my personal creds in the ci system or any other general infra system for this type of purpose. Does this make more sense now? Do you think this is a legitimate concern?