Security integration with state package.

Security integration with state package.

Provides for principals created when corrresponding states are
created that have agents associated.

https://code.launchpad.net/~hazmat/juju/states-with-principals/+merge/100783

(do not edit description out of merge proposal)

[hazmat, 2012-04-04 13:25:39]

Please take a look.

[niemeyer, 2012-04-04 14:32:11]

As we discussed before, this looks like a pretty significant change for that
point in time.

Either way, if you want to go with it, we need a written down description of
what is going on here in terms of changes to the public interfaces, as usual.

[hazmat, 2012-04-04 15:53:23]

On Wed, Apr 4, 2012 at 10:32 AM, <n13m3y3r@gmail.com> wrote:

> As we discussed before, this looks like a pretty significant change for
> that point in time.
>
> Either way, if you want to go with it, we need a written down
> description of what is going on here in terms of changes to the public
> interfaces, as usual.
>
>
https://codereview.appspot.**com/5966076/<https://codereview.appspot.com/5966...



It seems to be the number one concern regarding the failed MIR.

The implementation here is per the security spec discussed last fall,
incorporating feedback from the initial reviews. The spec is out of date
(uses ensemble instead of juju), and per feedback the OTP agent was dropped
for interceptable OTP tokens.

There aren't any public interface changes, just the imposition of ACLs onto
existing nodes.

I can update the spec and send it around to the list if you'd like.. but as
is, the components  can effectively be merged as the default security
policy is permissive, ie no functional delta till the policy is activated.

-k

[niemeyer, 2012-04-04 16:03:21]

On 2012/04/04 15:53:23, hazmat wrote:
> It seems to be the number one concern regarding the failed MIR.

My understanding is that the MIR has been dropped.

> The implementation here is per the security spec discussed last fall,
> incorporating feedback from the initial reviews. The spec is out of date
> (uses ensemble instead of juju), and per feedback the OTP agent was dropped
> for interceptable OTP tokens.
> 
> There aren't any public interface changes, just the imposition of ACLs onto
> existing nodes.

Please see the mailing list conversation about what "public changes" means. The
message subject is "Code reviews and public API changes".

> I can update the spec and send it around to the list if you'd like.. but as
> is, the components  can effectively be merged as the default security
> policy is permissive, ie no functional delta till the policy is activated.

The management of the Python code base is under your control, as we agreed. What
I'm concerned about is with changes that are landing without being debated for
12.04 (hint: we *are* in 04!).

[niemeyer, 2012-04-04 16:43:34]

On Wed, Apr 4, 2012 at 13:10, Kapil Thangavelu <kapil.thangavelu@canonical.com>
wrote:
>> On 2012/04/04 15:53:23, hazmat wrote:
>> > It seems to be the number one concern regarding the failed MIR.
>>
>> My understanding is that the MIR has been dropped.
>>
>
> hence the term 'failed'

If it's failed, it's not an argument to have changes going in now.

> ic. we've publicly debated these changes previously last fall,
> i believe your saying that that process needs to be done again?

Sorry, I don't want to frustrate you at all, but try to look from another
perspective: there's a release of Ubuntu *this month*, and we're rushing with a
Go implementation to catch up meanwhile. Then, there's that massive change set
that has seen zero debate in the mailing list. I hope it's not a surprise that
I'm asking more details.

Besides that, where's that previously reviewed document that you mention? It's
not linked from this proposal, and I can't find it anywhere.

[hazmat, 2012-04-04 17:43:36]

On Wed, Apr 4, 2012 at 12:43 PM, <n13m3y3r@gmail.com> wrote:

> On Wed, Apr 4, 2012 at 13:10, Kapil Thangavelu
> <kapil.thangavelu@canonical.**com <kapil.thangavelu@canonical.com>> wrote:
>
>> On 2012/04/04 15:53:23, hazmat wrote:
>>> > It seems to be the number one concern regarding the failed MIR.
>>>
>>
>  My understanding is that the MIR has been dropped.
>>>
>>
>
>  hence the term 'failed'
>>
>
> If it's failed, it's not an argument to have changes going in now.
>
>  ic. we've publicly debated these changes previously last fall,
>> i believe your saying that that process needs to be done again?
>>
>
> Sorry, I don't want to frustrate you at all, but try to look from
> another perspective: there's a release of Ubuntu *this month*, and we're
> rushing with a Go implementation to catch up meanwhile. Then, there's
> that massive change set that has seen zero debate in the mailing list. I
> hope it's not a surprise that I'm asking more details.
>
> Besides that, where's that previously reviewed document that you
> mention? It's not linked from this proposal, and I can't find it
> anywhere.
>
>
https://codereview.appspot.**com/5966076/<https://codereview.appspot.com/5966...


The mir failed in part because of lack of appropriate security, and the
security concerns remain an issue to adoption.

for reference this was the original spec
https://code.launchpad.net/~hazmat/juju/security-specification/+merge/63921

it was discussed in depth @ austin sprint
http://pad.ubuntu.com/cUU8nlRZ4U

i mispoke when i said it was previously discussed on list, while its
discussed in the context of several other threads, i don't see a dedicated
thread to it offhand.

what i'm asking for is direction wrt to your comments.. i've updated the
security branches and cleaned them up. If you'd like me to bring it up on
list, i'm happy to push the spec there. If its something that should be
dropped.. well then pls say that.. at this point clearly i'm not too
concerned about wasting time effort on dead code.

-k

[niemeyer, 2012-04-04 17:50:48]

On 2012/04/04 17:43:36, hazmat wrote:
> The mir failed in part because of lack of appropriate security, and the
> security concerns remain an issue to adoption.

A broken implementation is a much more serious concern for adoption.

> for reference this was the original spec
> https://code.launchpad.net/%7Ehazmat/juju/security-specification/+merge/63921

"Needs Fixing on 2011-06-09"

> what i'm asking for is direction wrt to your comments.. i've updated the
> security branches and cleaned them up. If you'd like me to bring it up on
> list, i'm happy to push the spec there. If its something that should be
> dropped.. well then pls say that.. at this point clearly i'm not too
> concerned about wasting time effort on dead code.

Do you want me to say one more time? Sure: I think it is a bad idea to be
merging massive changes for 12.04 at this stage. I would not do it. I would not
be merging all those significant changes right before a release. It's supposed
to be stable. Let's please not ship crack in 12.04.

[niemeyer, 2012-04-04 19:00:41]

On Wed, Apr 4, 2012 at 15:43, Clint Byrum <clint@fewbar.com> wrote:
> I think they are equally serious, and adoption will suffer on the backend
> (as people get more serious) if the security is not handled. One side of
> me says we should at least ship an insecure toy, so that people can try
> it out. But the other hand says we already did that in 11.10, and doing
> so again would only waste peoples' time who are actively looking to deploy
> with juju. Perhaps its better that we ship secure with bugs than insecure
> with less bugs, and push hard to fix those problems as they are found.

This was a great topic for us to have had at the last UDS. It's now
time to ship 12.04, which was supposed to be a stable release, in my
humble opinion.

> Perhaps we can defer the large impact that this work carries until
> after 12.04 releases, and instead focus on just fixing the "wide open
> zookeeper" problem with a minimal patch that just adds a basic ACL like
> "anonymous can't do anything", and be able to pass generated credentials
> to each node?

That sounds less complex and thus preferable as an entry point. It was
once the whole point of that never-used admin-secret setting, by the
way.

That said, I'd still postpone that to 12.04.1. It's time to stop changing
juju and preparing for an actual release. I can use juju in EC2 knowing
zookeeper is open. I won't use juju anywhere if it breaks all the time.

[hazmat, 2012-04-04 19:02:10]

On Wed, Apr 4, 2012 at 1:50 PM, <n13m3y3r@gmail.com> wrote:

> On 2012/04/04 17:43:36, hazmat wrote:
>
>> The mir failed in part because of lack of appropriate security, and
>>
> the
>
>> security concerns remain an issue to adoption.
>>
>
> A broken implementation is a much more serious concern for adoption.


its unclear how the implementation which has yet to land got classified as
broken.

[niemeyer, 2012-04-04 19:13:54]

On 2012/04/04 19:02:10, hazmat wrote:
> its unclear how the implementation which has yet to land got classified as
> broken.

Kapil, it's your take. I'm not going to be the bad guy again. If you want to
release this work in 12.04, just provide an up-to-date document explaining in
detail what's being suggested as far as the external interactions go, and I'll
review.

[hazmat, 2012-04-04 19:35:17]

On 2012/04/04 19:13:54, niemeyer wrote:
> On 2012/04/04 19:02:10, hazmat wrote:
> > its unclear how the implementation which has yet to land got classified as
> > broken.
> 
> Kapil, it's your take. I'm not going to be the bad guy again. If you want to
> release this work in 12.04, just provide an up-to-date document explaining in
> detail what's being suggested as far as the external interactions go, and I'll
> review.

all right given the effort and timeline it seems more important to work on bug
fixes for 12.04 instead of this. i'll bring it back up  post release for 12.04.1

[hazmat, 2012-08-28 16:12:22]

Please take a look.