Keystone Private Key not securely sent to host

[Gregory Haynes]

We now use heat + oac to send the keystone ssl key to the keystone host. This is not a secure communication channel and leaves the key permanently stored in bothe the heat database and available via the cfn api.

[Clint Byrum (clint-fewbar)]

11:17 < greghaynes> ok, I can take on assessing it since im pretty familiar with whats going on

Proof he wants this. ;)

[Gregory Haynes (greghaynes)]

So this is an issue for a couple reasons:

* We appear to be using http (not TLS) to hit the cfn endpoint.
* Anyone who can spoof an IP and has the OS_* credentials can simply request this data (all the nodes that makes up a cloud, basically)

Additionally, were transmitting db passwords using this same mechanism. This means that even if we transmit the keystone key out of band anyone can get they keystone db password and then grab tokens out of the db.

[Gregory Haynes (greghaynes)]

Some new priorities have come up and I wont have time to hash this out. This is still a serious issue, though.

[Robert Collins (lifeless)]

I don't think is as critical as portrayed... anyone who has the OS_* credentials can just pull the stack details anyway, no IP spoofing needed.

The use of HTTP rather than HTTPS is indeed a concern, though of course the TFTP stage is also attackable.

As far as the details being in heat being a concern: as our source of config, if heat is compromised, it can cause havoc in nearly every fashion.

tl;dr I think the plan of using barbican when its stable is still good, but we don't need to panic.

[Gregory Haynes (greghaynes)]

If we want to consider all hosts in our cluster at the same priviledge level then thats ok. I would like to think that a compromised compute node would not compromise the entire cluster, but if AIUI its trivial for a compute node to request the CFN data for the whole stack.

[Emilien Macchi (emilienm)]

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, NEWTON, OCATA, PIKE, PIKE).
  Valid example: CONFIRMED FOR: LIBERTY