Re: Juju as a snap

2016-08-07 Thread Stuart Bishop 
On 3 August 2016 at 04:00, Nicholas Skaggs 
wrote:

> The Juju client has been snappified and pushed to the juju store. Note for
> now it's just an amd64 build.
>
> snap install juju --beta --devmode
>
> The beta channel contains the latest beta, 2.0-beta13. This is a sneak
> preview of further builds, including the latest crack available in the edge
> channel as development happens.
>

You might want to get the snap added to the normal release process...
beta14 is the new hotness.

(Launchpad can do automatic builds of multiple architectures from a git or
bzr branch, and push them to the charm store for you)


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

juju @ conjure-up on Power8 , Free Trial on SoftLayer

2016-08-07 Thread Khairul Aizat Kamarudzzaman 
Hi,
I've tried and its not possible to run conjure-up and container to deploy
big software on Power8 Softlayer as current the hardware doesn't supported
Xenial Xerus yet.

event the kernel itself doesn't support kvm_intel module. Appreciate if
someone can advise me how can I fully utilize the trial period and give
feedback to improve for future Ubuntu support on Power8


Thanks & Regards,
Khairul Aizat Kamarudzzaman
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Secrets

2016-08-07 Thread John Meinel 
>
> ...
>


> Sure, an example:
>
> A web application needs creds (secrets) in order to access a 3rd party
> api. These creds need to exist in a config file on the webserver/instance.
> As a user, you/I know what the secrets are, but now we need to share them
> with the web application, and only the web application in order for the
> webapp to connect to the 3rd party api.
>
> Who are we hiding the information from?
>
> Considering the above example, restricting access to the “secrets” from
> any entity outside of the one that would need access to them to provision
> them seems like a reasonable approach. That being said, I feel like access
> restrictions should be at the charm/layer level.
>
So how does a charm/layer prove who it is, such that nobody else can do
that proof? Juju tracks what charms are deployed to what machine, and each
unit agent ends up having its own login back to the Controller. However,
all charms hooks are run as 'root' on the machine (they sort of have to,
because they need to do stuff like install software). Which means they can
read any files that exist on the machine.

So there is very little we could do at the 'layer' level, aside from
pretend that the information couldn't be read. (We could have a secret key
for a layer, but where could that layer store its secret that any other
software running as root on that machine couldn't get access to.)

You also have to be a little careful if you ever install 2 charms on the
same machine (juju deploy foo --to 1), because then both bits of software
could read the secrets that were for the other software. (Worst case, they
just read the configuration of the actual service, which must have some way
to get the unencrypted form, or it couldn't do its job.)

As is, we don't allow agents to read the data for other agents. (The agent
for machine-1 could ask for the details of machine-2, but will get told
EPERM).

If we aren't hiding the values from the *user* then simple application
config is already secret. There may be bugs, but by design the only thing
that can read the config for an application is the agents for the units of
that application, the controller itself, and the user.

Now, there is a case for maybe storing the secrets encrypted on the
controller, but again, all of the information for how to get the secrets
out have to be in the system, so that *someone* could make use of them.

One thought, we could improve things slightly over the status quo if we had
each agent create a public/private key pair and register it, and then
anything flagged 'secret' gets encrypted with the agents public key, and
the agent stores its private key somewhere on the machine-local disk. Then
when a user enters secrets, we encrypt the values with that public key, and
not even the controller has access anymore. Still can't do per-layer
secrets (cause where can a layer store a secret that another layer in the
same charm can't get to it)? But we could cut out the ability for anything
but software running on that machine to read it. I'm not sure if the
cost/benefit is really there, as if you want to deploy 2 units of the
software, you have to re-encrypt the original settings for the second unit,
and if the Controller doesn't have access to the original text, then it
can't encrypt it for the second unit. The User has to re-enter the
software. Likely we also need a public/private key that the User tracks, if
they ever want to 'get' the value back. And I guess we could make it so
'add-unit' interacts with the User, who can decrypt the content with the
User's key, and then encrypt it back with the agents public key.

Its a lot of hassle, with the one advantage that getting access to the
Controller doesn't give you access to the secrets of all software that has
been configured.

But I have the feeling that for your actual use case, just the fact that
the Controller doesn't let anyone but the
agent-in-charge-of-that-application read the values for that application is
actually enough.




> Two possibilities I’ve thought of:
>
> A) Layer Sensitive Secrets - I’m thinking a secret might only be readable
> to the layer in which it is configured to be used. A secret could be
> context sensitive to the :, such that when you set a secret in a model, you
> are setting it such that it can only be accessed by a named layer in named
> charm.
>
> B) Shared Model Secrets - Less restrictive “secrets”, accessible globally,
> at the model level.
>
> Are we hiding information from the Juju users?
>
> When a secret is set, it could be hashed before being stored in the
> database, then other users who are members of the same model wouldn’t be
> able to see what the secret was, but they could see that it exists by
> listing secrets.
>
> Are we trying to hide information from other processes on the same
> machines as the agents?
>
> I think the process isolation would come along for the ride inherently as
> long as processes and directories have their permissions locked down
>

Re: Juju Secrets

2016-08-07 Thread John Meinel 
>
> ...
>


> Sure, an example:
>
> A web application needs creds (secrets) in order to access a 3rd party
> api. These creds need to exist in a config file on the webserver/instance.
> As a user, you/I know what the secrets are, but now we need to share them
> with the web application, and only the web application in order for the
> webapp to connect to the 3rd party api.
>
> Who are we hiding the information from?
>
> Considering the above example, restricting access to the “secrets” from
> any entity outside of the one that would need access to them to provision
> them seems like a reasonable approach. That being said, I feel like access
> restrictions should be at the charm/layer level.
>
So how does a charm/layer prove who it is, such that nobody else can do
that proof? Juju tracks what charms are deployed to what machine, and each
unit agent ends up having its own login back to the Controller. However,
all charms hooks are run as 'root' on the machine (they sort of have to,
because they need to do stuff like install software). Which means they can
read any files that exist on the machine.

So there is very little we could do at the 'layer' level, aside from
pretend that the information couldn't be read. (We could have a secret key
for a layer, but where could that layer store its secret that any other
software running as root on that machine couldn't get access to.)

You also have to be a little careful if you ever install 2 charms on the
same machine (juju deploy foo --to 1), because then both bits of software
could read the secrets that were for the other software. (Worst case, they
just read the configuration of the actual service, which must have some way
to get the unencrypted form, or it couldn't do its job.)

As is, we don't allow agents to read the data for other agents. (The agent
for machine-1 could ask for the details of machine-2, but will get told
EPERM).

If we aren't hiding the values from the *user* then simple application
config is already secret. There may be bugs, but by design the only thing
that can read the config for an application is the agents for the units of
that application, the controller itself, and the user.

Now, there is a case for maybe storing the secrets encrypted on the
controller, but again, all of the information for how to get the secrets
out have to be in the system, so that *someone* could make use of them.

One thought, we could improve things slightly over the status quo if we had
each agent create a public/private key pair and register it, and then
anything flagged 'secret' gets encrypted with the agents public key, and
the agent stores its private key somewhere on the machine-local disk. Then
when a user enters secrets, we encrypt the values with that public key, and
not even the controller has access anymore. Still can't do per-layer
secrets (cause where can a layer store a secret that another layer in the
same charm can't get to it)? But we could cut out the ability for anything
but software running on that machine to read it. I'm not sure if the
cost/benefit is really there, as if you want to deploy 2 units of the
software, you have to re-encrypt the original settings for the second unit,
and if the Controller doesn't have access to the original text, then it
can't encrypt it for the second unit. The User has to re-enter the
software. Likely we also need a public/private key that the User tracks, if
they ever want to 'get' the value back. And I guess we could make it so
'add-unit' interacts with the User, who can decrypt the content with the
User's key, and then encrypt it back with the agents public key.

Its a lot of hassle, with the one advantage that getting access to the
Controller doesn't give you access to the secrets of all software that has
been configured.

But I have the feeling that for your actual use case, just the fact that
the Controller doesn't let anyone but the
agent-in-charge-of-that-application read the values for that application is
actually enough.




> Two possibilities I’ve thought of:
>
> A) Layer Sensitive Secrets - I’m thinking a secret might only be readable
> to the layer in which it is configured to be used. A secret could be
> context sensitive to the :, such that when you set a secret in a model, you
> are setting it such that it can only be accessed by a named layer in named
> charm.
>
> B) Shared Model Secrets - Less restrictive “secrets”, accessible globally,
> at the model level.
>
> Are we hiding information from the Juju users?
>
> When a secret is set, it could be hashed before being stored in the
> database, then other users who are members of the same model wouldn’t be
> able to see what the secret was, but they could see that it exists by
> listing secrets.
>
> Are we trying to hide information from other processes on the same
> machines as the agents?
>
> I think the process isolation would come along for the ride inherently as
> long as processes and directories have their permissions locked down
>

Re: juju run-action --application?

2016-08-07 Thread John Meinel 
On Aug 4, 2016 1:36 AM, "Matthew Williams" 
wrote:
>
> Those are all good points - but they also seem like implementation
details. For example if an action relied on coordination around the leader
then the action should be written to protect against that - since it may
still break if the user was to run juju run-action myapp/0 && juju
run-action myapp/1.
>
> My question is - if I have a model with an application scaled to 10
units, and I know the action is safe to run all the units why do I have to
call run-action 10 times, shouldn't I just be able to call it once on the
application? Is there a genuine reason we're not supporting this?
>
> Cheers
>
> Matty

Having it follow the logic of 'juju run' and just trigger the action on all
units  (who could then coordinate what should actually be run with eg an
"is-leader" check seems reasonable). Otherwise the user has to run
is-leader to figure out where it should be run, and there will be an
inherent race that the leader could change before they run the action.

Please raise a bug for this and we'll try to see how we can schedule the
work.

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

Re: Automate the creation of Juju environments on MAAS

2016-08-07 Thread John Meinel 
I thought in MAAS 2 they have a way to generate a file appropriate for
being a .maasrc file which Juju will use as a source for 'juju
autoload-credentials'. That doesn't do the steps of creating the MAAS user
itself, but it should help the 'configure juju' part. Though this will also
only be supported in Juju 2.0

John
=:->

On Aug 4, 2016 11:05 AM, "Merlijn Sebrechts" 
wrote:

> Hi all
>
>
> I'd like to automate the creation of Juju environments on MAAS. Automate
> stuff like:
>
> - Creating users
> - Creating API keys
> - Configuring the Juju client
>
> Is there something available that does this? If not, I'll write it myself
> but I wanted to check the list first.
>
>
>
>
> Kind regards
> Merlijn
>
> --
> 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