Let administrators see the region secret in the MAAS UI, and provide instructions on how to register clusters.

[Christian Reis]

With the new RPC security mechanism, the administrator will need to run a commandline utility on the cluster to set the correct secret for its region region. It would be a nice touch if the MAAS UI showed the secret, to admins only, in a way which could be disclosed and copy/pasted into a commandline on the cluster.

[Julian Edwards (julian-edwards)]

Ummm this is a little odd. Let me explain:

The old celery-based startup script connected with the region using a self-generated UUID, which is how the region uniquely IDs each cluster.

Upon each cluster startup connection, the region looked at the cluster status and if it's unknown, it says "go away for now but I may let you in later", and a new cluster is flagged for the admin to accept or not. If it's known, then the cluster connection is either accepted or rejected depending on what the admin previously did. If it's accepted, the secrets are sent back to the cluster so it can complete the (secure) connection.

If this process has gone manual for RPC style, then I consider this a regression that needs to be fixed. The admin should not need to know any secrets, it was designed to be easy to use and automatic.

[Julian Edwards (julian-edwards)]

And I should say that the startup negotiation was done on the API using a wrapper script which can talk over https to the region, so it was secure.

[Gavin Panella (allenap)]

> Ummm this is a little odd. Let me explain:
>
> The old celery-based startup script connected with the region using a
> self-generated UUID, which is how the region uniquely IDs each
> cluster.
>
> Upon each cluster startup connection, the region looked at the cluster
> status and if it's unknown, it says "go away for now but I may let you
> in later", and a new cluster is flagged for the admin to accept or
> not. If it's known, then the cluster connection is either accepted or
> rejected depending on what the admin previously did. If it's accepted,
> the secrets are sent back to the cluster so it can complete the
> (secure) connection.

The region hands out credentials to anyone with the clusters UUID. Now,
that UUID is not treated as a secure token, it's even used in URLs on in
the web UI and the remote API. HTTPS or not, this is almost entirely
insecure.

>
> If this process has gone manual for RPC style, then I consider this a
> regression that needs to be fixed. The admin should not need to know
> any secrets, it was designed to be easy to use and automatic.

In terms of user experience, you're right. In terms of actual security,
it's a large improvement.

>
> And I should say that the startup negotiation was done on the API
> using a wrapper script which can talk over https to the region, so it
> was secure.

HTTPS does not equal secure. It means the traffic cannot be sniffed in
transit and, if you're validating chains of trust, it also gives you
protection against MITM. But this is academic when the region will hand
you the traffic in exchange for an insecure token. The weakest link
isn't the comms traffic.

[Gavin Panella (allenap)]

> > If this process has gone manual for RPC style, then I consider this
> > a regression that needs to be fixed. The admin should not need to
> > know any secrets, it was designed to be easy to use and automatic.
>
> In terms of user experience, you're right. In terms of actual
> security, it's a large improvement.

I should have mentioned that we have done some back-and-forth on the
user experience. I think we all have concerns about this change, but
some kind of break is necessary at some point to give us some actual
security. We have also discussed this with stakeholders and they are
okay with it, if not exactly jubilant.

[Julian Edwards (julian-edwards)]

On Thursday 09 Oct 2014 08:30:42 you wrote:
> > Ummm this is a little odd. Let me explain:
> >
> > The old celery-based startup script connected with the region using a
> > self-generated UUID, which is how the region uniquely IDs each
> > cluster.
> >
> > Upon each cluster startup connection, the region looked at the cluster
> > status and if it's unknown, it says "go away for now but I may let you
> > in later", and a new cluster is flagged for the admin to accept or
> > not. If it's known, then the cluster connection is either accepted or
> > rejected depending on what the admin previously did. If it's accepted,
> > the secrets are sent back to the cluster so it can complete the
> > (secure) connection.
>
> The region hands out credentials to anyone with the clusters UUID. Now,
> that UUID is not treated as a secure token, it's even used in URLs on in
> the web UI and the remote API. HTTPS or not, this is almost entirely
> insecure.

Christ. So why don't we have a separate token that's auto-generated?

> > If this process has gone manual for RPC style, then I consider this a
> > regression that needs to be fixed. The admin should not need to know
> > any secrets, it was designed to be easy to use and automatic.
>
> In terms of user experience, you're right. In terms of actual security,
> it's a large improvement.

Only in terms of the fact that the "token" is not in the URL any more.

> > And I should say that the startup negotiation was done on the API
> > using a wrapper script which can talk over https to the region, so it
> > was secure.
>
> HTTPS does not equal secure. It means the traffic cannot be sniffed in
> transit and, if you're validating chains of trust, it also gives you
> protection against MITM. But this is academic when the region will hand
> you the traffic in exchange for an insecure token. The weakest link
> isn't the comms traffic.

I didn't say HTTPS was secure in itself, I was implying that as long as the
token is not exposed anywhere then the transport itself is not going to reveal
it either.

Is there any reason why we can't go back to an automatic token setup generated
on the cluster itself?

[Gavin Panella (allenap)]

> > The region hands out credentials to anyone with the clusters UUID.
> > Now, that UUID is not treated as a secure token, it's even used in
> > URLs on in the web UI and the remote API. HTTPS or not, this is
> > almost entirely insecure.
>
> Christ. So why don't we have a separate token that's auto-generated?

That's kind of what the shared-secret is, except we don't need to ship
it over the network other than the one time that the admin copies it to
the cluster (when he/she is at liberty to be as secure or insecure as
they like).

Putting it in the UI is a potential leak, because it will then be
transmitted over the wire, though only to a password-authenticated
admin. It may be better therefore to have a command-line tool to obtain
the secret and only put instructions in the UI.

>
> > > If this process has gone manual for RPC style, then I consider
> > > this a regression that needs to be fixed. The admin should not
> > > need to know any secrets, it was designed to be easy to use and
> > > automatic.
> >
> > In terms of user experience, you're right. In terms of actual
> > security, it's a large improvement.
>
> Only in terms of the fact that the "token" is not in the URL any more.

A cluster can prove to the region and the region can prove to the
cluster that is has a shared-secret without sending it over the wire.
This means we don't leak tokens even on a non-SSL/TLS connection.

>
> > HTTPS does not equal secure. It means the traffic cannot be sniffed
> > in transit and, if you're validating chains of trust, it also gives
> > you protection against MITM. But this is academic when the region
> > will hand you the traffic in exchange for an insecure token. The
> > weakest link isn't the comms traffic.
>
> I didn't say HTTPS was secure in itself, I was implying that as long
> as the token is not exposed anywhere then the transport itself is not
> going to reveal it either.
>
> Is there any reason why we can't go back to an automatic token setup
> generated on the cluster itself?

Without some kind of out-of-band validation of trust there's no way of
doing this securely. Neither the cluster nor the region knows that it's
talking to the other and not a bad actor in the middle, so transmitting
the secure token over that channel means you lose all security. Having a
shared-secret that we never transmit means that we retain a mechanism
for mutually validating who's on each side of a conversation, even if
communications between the cluster and region are insecure. This gives
us a leg-up to having full TLS between the region and clusters without
an additional manual step.