Re: admin is dead, long live $USER

2016-03-06 Thread Tim Penhey 
Ah yeah... it is mostly coming back to me now.

I actually have a branch lying around that does most of this.

Perhaps I should look at it again :-)

Tim

On 04/03/16 20:08, Ian Booth wrote:
> Hey Tim
> 
> The new bootstrap UX has not removed any --admin-user flag.
> I can see that the server jujud bootstrap command has an --admin-user argument
> but it appears this is never set anywhere in the cloud init scripts. Or not 
> that
> I can see. I've checked older version of the relevant files and can't see 
> where
> we've ever used this.
> 
> So maybe we have a capability to bootstrap the controller agent with a 
> specified
> admin-user but have not hooked it up yet?
> 
> On 04/03/16 08:11, Tim Penhey wrote:
>> Ah... it used to be there :-) At least it is on my feature branch, but I
>> don't think I have merged the most recent master updates that has the
>> work to re-work bootstrap for the new cloud credentials stuff.
>>
>> Tim
>>
>> On 04/03/16 10:09, Rick Harding wrote:
>>> If we do that we need to also make it configurable on bootstrap as an
>>> option.
>>>
>>> +1 overall
>>>
>>>
>>> On Thu, Mar 3, 2016, 4:07 PM Tim Penhey >> > wrote:
>>>
>>> Hi folks,
>>>
>>> I was thinking that with the upcoming big changes with 2.0, we should
>>> tackle a long held issue where we have the initial user called "admin".
>>>
>>> There was a request some time back that we should use the current user's
>>> name. The reason it wasn't implemented at that time was due to logging
>>> into the GUI issues. These have been resolved some time back with the
>>> multiple user support that was added.
>>>
>>> All the server side code handles the ability to define the initial user
>>> for the controller model, and we do this in all the tests, so the
>>> default test user is actually called "test-admin".
>>>
>>> I *think* that all we need to do is change the default value we use in
>>> the bootstrap command for the AdminUserName (--admin-user flag) from
>>> "admin" to something we derive from the current user.
>>>
>>> Probably worth doing now.
>>>
>>> Thoughts?
>>>
>>> Tim
>>>
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com 
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>
>>


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

Re: [Juju] Minimum policies for Juju to work on public clouds

2016-03-06 Thread Samuel Cozannet 
Yeah, I tried to add the VPC as well, but didn't work either. There is
something about the "bucket" created at the beginning, I thought S3 perms
would do, but no luck.




--
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 Sun, Mar 6, 2016 at 2:41 PM, Tom Barber  wrote:

> Do you need to offer up some VPC permissions as well on VPC default EC2
> accounts?
> On 6 Mar 2016 13:24, "Samuel Cozannet" 
> wrote:
>
>> Hi All,
>>
>> I have been setting up many different environments on AWS, GCE, Azure
>> (...), but my most used cloud by far until now has been AWS.
>>
>> The way I have operated until now is to create an admin group in IAM,
>> then adding users in it for my demos, and use their credentials in the
>> environment file.
>> This means Juju has "full power" on my AWS environment, to the extend it
>> could create additional users. Furthermore, if I share my environment with
>> someone, I am "giving" my AWS account away essentially. Not cool.
>> Hence I tried to find the minimum policy (or group of policies) I should
>> apply to make it work without giving away too much power.
>>
>> Juju seems to work fine with PowerUser perms, which is everything minus
>> user management. A good start, but still too much for me.
>>
>> Then when I tried to restrict further,
>> * FullEC2Access: not sufficient, fails to bootstrap
>> * FullEC2 + FullS3: not sufficient, fails to bootstrap
>> The error I get is :
>> ERROR failed to bootstrap environment: cannot start bootstrap instance:
>> recording instance in provider-state: cannot write file "provider-state" to
>> control bucket: The specified bucket does not exist
>>
>> ==> Is there a recommended set of policies somewhere? I'd love to see
>> that in the docs as well, with advice for each cloud.
>>
>> Thanks,
>> Sam
>>
>>
>> --
>> 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

Re: [Juju] Minimum policies for Juju to work on public clouds

2016-03-06 Thread Tom Barber 
Do you need to offer up some VPC permissions as well on VPC default EC2
accounts?
On 6 Mar 2016 13:24, "Samuel Cozannet" 
wrote:

> Hi All,
>
> I have been setting up many different environments on AWS, GCE, Azure
> (...), but my most used cloud by far until now has been AWS.
>
> The way I have operated until now is to create an admin group in IAM, then
> adding users in it for my demos, and use their credentials in the
> environment file.
> This means Juju has "full power" on my AWS environment, to the extend it
> could create additional users. Furthermore, if I share my environment with
> someone, I am "giving" my AWS account away essentially. Not cool.
> Hence I tried to find the minimum policy (or group of policies) I should
> apply to make it work without giving away too much power.
>
> Juju seems to work fine with PowerUser perms, which is everything minus
> user management. A good start, but still too much for me.
>
> Then when I tried to restrict further,
> * FullEC2Access: not sufficient, fails to bootstrap
> * FullEC2 + FullS3: not sufficient, fails to bootstrap
> The error I get is :
> ERROR failed to bootstrap environment: cannot start bootstrap instance:
> recording instance in provider-state: cannot write file "provider-state" to
> control bucket: The specified bucket does not exist
>
> ==> Is there a recommended set of policies somewhere? I'd love to see that
> in the docs as well, with advice for each cloud.
>
> Thanks,
> Sam
>
>
> --
> 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

[Juju] Minimum policies for Juju to work on public clouds

2016-03-06 Thread Samuel Cozannet 
Hi All,

I have been setting up many different environments on AWS, GCE, Azure
(...), but my most used cloud by far until now has been AWS.

The way I have operated until now is to create an admin group in IAM, then
adding users in it for my demos, and use their credentials in the
environment file.
This means Juju has "full power" on my AWS environment, to the extend it
could create additional users. Furthermore, if I share my environment with
someone, I am "giving" my AWS account away essentially. Not cool.
Hence I tried to find the minimum policy (or group of policies) I should
apply to make it work without giving away too much power.

Juju seems to work fine with PowerUser perms, which is everything minus
user management. A good start, but still too much for me.

Then when I tried to restrict further,
* FullEC2Access: not sufficient, fails to bootstrap
* FullEC2 + FullS3: not sufficient, fails to bootstrap
The error I get is :
ERROR failed to bootstrap environment: cannot start bootstrap instance:
recording instance in provider-state: cannot write file "provider-state" to
control bucket: The specified bucket does not exist

==> Is there a recommended set of policies somewhere? I'd love to see that
in the docs as well, with advice for each cloud.

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