Juju should only give security warnings on bootstrap

Bug #1012497 reported by Ted Gould
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
pyjuju
Triaged
Low
Unassigned

Bug Description

Juju has several warnings to tell users that the situation they're deploying in has the ability to be attacked. One of those is if you're using http URLs in an ec2 provider. The warnings are like this:

2012-06-12 23:47:06,123 WARNING EC2 API calls not using secure transport
2012-06-12 23:47:06,123 WARNING S3 API calls not using secure transport

These warnings, while informative, come way too often. For instance, when deploying you can get them up to eight times. This isn't useful information as the user rarely has control over these URLs, but should know the situation that they're in at some point. I think that point is during bootstrap. When creating the boot strap Juju should warn about the insecure environment, and beyond that should assume the user has been told about their setup.

Tags: security
Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Hi Ted, thanks for opening this.

Bootstrap isn't quite strong enough. In a real world example, bootstrap may happen once, and then many admins will come along afterward and can *change* the environment URLs in their own copy of environments.yaml.

I think the right thing to do is to provide an option to suppress these warnings per-environment.

we have ssl-hostname-verification: (bool) already. Lets add 'ignore-insecure-transport: (bool)'. We can default it to false, and then change the message to something like this:

2012-06-12 23:47:06,123 WARNING EC2 API calls not using secure transport (ignore-insecure-transport=False)

Sound good?

Revision history for this message
Ted Gould (ted) wrote : Re: [Bug 1012497] Re: Juju should only give security warnings on bootstrap

On Wed, 2012-06-13 at 16:56 +0000, Clint Byrum wrote:
> Sound good?

It solves my use case, but I don't think you're really getting any
stronger of a warning. The reality is that people sharing an Juju setup
are likely to be just passing around an environments.yaml file anyway,
so once the first admin sets it no one else will notice. Seems roughly
the same as bootstrap in that regard.

Revision history for this message
Clint Byrum (clint-fewbar) wrote :

Excerpts from Ted Gould's message of 2012-06-13 17:40:20 UTC:
> On Wed, 2012-06-13 at 16:56 +0000, Clint Byrum wrote:
> > Sound good?
>
> It solves my use case, but I don't think you're really getting any
> stronger of a warning. The reality is that people sharing an Juju setup
> are likely to be just passing around an environments.yaml file anyway,
> so once the first admin sets it no one else will notice. Seems roughly
> the same as bootstrap in that regard.
>

Right I see that it seems a bit the same, and the difference is basically
just nuance.

In the case you bring up, the user who set 'ignore-insecure-transport:
true' will have been doing it to suppress warnings about http:// urls
which are also only ever set in the environments.yaml (defaults are all
https). So if they share that, so be it, its already been expressed in
the way the sharing team of admins wants it expressed. However if they
share an environments.yaml without URLs set, or with https urls set,
its unlikely they'll also have ignore-insecure-transport set, so then
when the receiver of said environments.yaml goes in and changes the URL
to http://, they're likely to see the warning and then make a conscious
decision as to whether to suppress the warning or go back to https,
which is what we want.

Changed in juju:
status: New → Confirmed
importance: Undecided → Medium
tags: added: security
Curtis Hovey (sinzui)
Changed in juju:
status: Confirmed → Triaged
Curtis Hovey (sinzui)
Changed in juju:
importance: Medium → Low
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.