Re: User Mgmt - 2.0 and Beyond

2016-06-01 Thread Mark Shuttleworth 

Yes, this is super interesting. Thanks!


On 01/06/16 10:58, James Beedy wrote:
> I've "conjured-up" what I think would be a great enhancement to the current 
> user mgmt capability in 2.0. 
>
> As things stand, one can add a user to a model, and set a permission category 
> of either read (read), or write (read/write). This functionality is awesome, 
> and a huge step for juju (applause)! 
>
> Admins of juju can now create, manage, and maintain the users and users 
> access policy associated with a model (applause, again, seriously). 
>
> As a logical next step, why don't we take the user all the way to the 
> instance?
>
> What I'm thinking of is an '--os' flag that could be specified on user 
> creation!
>
> This flag would signify that the user need be created on the instances in the 
> current model. Ssh keys key(s) for a user could be added, and *associated*, 
> and provisioned alongside the respective user, and user account on the 
> machine.
>
> This functionality would give juju deployed infrastructure a huge edge in the 
> ease of user management/maintainability for any organization, and massive 
> bragging rights in enterprise land due to the increased PCI compliance 
> revolving around finer granularity in user access accounts.
>
> I feel like the majority of the big pieces are already In place, the primary 
> road blocks I foresee (probably a lot more):
> 1. User sensitive ssh-keys
> 2. Machine-level user provisioning template /UserManagerModel 
> 3. Os-level user access/permission policy (what is generic/default yet tuned 
> and hardened?)
>
>
> That about wraps it up, hopefully I got my point across to some degree.
>
> Thoughts?
>
>
>


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: User Mgmt - 2.0 and Beyond

2016-06-01 Thread Samuel Cozannet 
Good start. I would add

* external AAA connectivity (LDAP/AD) to find where the actual data is
stored.
* add user to units only (no access to Juju)
* share

++
Sam


--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu   / Canonical UK LTD  / Juju

samuel.cozan...@canonical.com
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]


On Wed, Jun 1, 2016 at 10:58 AM, James Beedy  wrote:

> I've "conjured-up" what I think would be a great enhancement to the
> current user mgmt capability in 2.0.
>
> As things stand, one can add a user to a model, and set a permission
> category of either read (read), or write (read/write). This functionality
> is awesome, and a huge step for juju (applause)!
>
> Admins of juju can now create, manage, and maintain the users and users
> access policy associated with a model (applause, again, seriously).
>
> As a logical next step, why don't we take the user all the way to the
> instance?
>
> What I'm thinking of is an '--os' flag that could be specified on user
> creation!
>
> This flag would signify that the user need be created on the instances in
> the current model. Ssh keys key(s) for a user could be added, and
> *associated*, and provisioned alongside the respective user, and user
> account on the machine.
>
> This functionality would give juju deployed infrastructure a huge edge in
> the ease of user management/maintainability for any organization, and
> massive bragging rights in enterprise land due to the increased PCI
> compliance revolving around finer granularity in user access accounts.
>
> I feel like the majority of the big pieces are already In place, the
> primary road blocks I foresee (probably a lot more):
> 1. User sensitive ssh-keys
> 2. Machine-level user provisioning template /UserManagerModel
> 3. Os-level user access/permission policy (what is generic/default yet
> tuned and hardened?)
>
>
> That about wraps it up, hopefully I got my point across to some degree.
>
> Thoughts?
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

User Mgmt - 2.0 and Beyond

2016-06-01 Thread James Beedy 
I've "conjured-up" what I think would be a great enhancement to the current 
user mgmt capability in 2.0. 

As things stand, one can add a user to a model, and set a permission category 
of either read (read), or write (read/write). This functionality is awesome, 
and a huge step for juju (applause)! 

Admins of juju can now create, manage, and maintain the users and users access 
policy associated with a model (applause, again, seriously). 

As a logical next step, why don't we take the user all the way to the instance?

What I'm thinking of is an '--os' flag that could be specified on user creation!

This flag would signify that the user need be created on the instances in the 
current model. Ssh keys key(s) for a user could be added, and *associated*, and 
provisioned alongside the respective user, and user account on the machine.

This functionality would give juju deployed infrastructure a huge edge in the 
ease of user management/maintainability for any organization, and massive 
bragging rights in enterprise land due to the increased PCI compliance 
revolving around finer granularity in user access accounts.

I feel like the majority of the big pieces are already In place, the primary 
road blocks I foresee (probably a lot more):
1. User sensitive ssh-keys
2. Machine-level user provisioning template /UserManagerModel 
3. Os-level user access/permission policy (what is generic/default yet tuned 
and hardened?)


That about wraps it up, hopefully I got my point across to some degree.

Thoughts?



-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

User Mgmt - 2.0 and Beyond

2016-06-01 Thread James Beedy 
I've "conjured-up" what I think would be a great enhancement to the current 
user mgmt capability in 2.0. 

As things stand, one can add a user to a model, and set a permission category 
of either read (read), or write (read/write). This functionality is awesome, 
and a huge step for juju (applause)! 

Admins of juju can now create, manage, and maintain the users and users access 
policy associated with a model (applause, again, seriously). 

As a logical next step, why don't we take the user all the way to the instance?

What I'm thinking of is an '--os' flag that could be specified on user creation!

This flag would signify that the user need be created on the instances in the 
current model. Ssh keys key(s) for a user could be added, and *associated*, and 
provisioned alongside the respective user, and user account on the machine.

This functionality would give juju deployed infrastructure a huge edge in the 
ease of user management/maintainability for any organization, and massive 
bragging rights in enterprise land due to the increased PCI compliance 
revolving around finer granularity in user access accounts.

I feel like the majority of the big pieces are already In place, the primary 
road blocks I foresee (probably a lot more):
1. User sensitive ssh-keys
2. Machine-level user provisioning template /UserManagerModel 
3. Os-level user access/permission policy (what is generic/default yet tuned 
and hardened?)


That about wraps it up, hopefully I got my point across to some degree.

Thoughts?



-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev