Open gozer opened 9 years ago
In one account per app, once a machine is compromised, the app is compromised.
This then doesn't become any escalation of compromise or privileges.
@gene1wood Can you provide me a link to this on the RRA? I need it to know what the risk level is currently. - Thanks
Use credstash or sneaker or similar tool to get the shared key through KMS or similar tool.
The risk ID in the RRA that links to this issue is the title of this issue, #insecuregossipsecret
, and linked in @gozer 's description
To add some information here, gossip secrets are now (for a while now) being obtained by instances over http, indeed, but via an endpoint only accessible from inside the VPC, not available over the internet anymore.
Trying to understand if that is sufficient to consider closing the risk.
And I'd like to correct a quote from the RRA:
"Insecure Consul gossip authentication allows for impersonation of services"
The particular secret this RRA is talking about is Consul's gossip protocol (implemented by Serf), and is only the underlying mechanism that provides cluster membership and failure detection. For instance, the Serf threat model only includes:
So, from my understanding, the gossip secret in no way compromises the catalog (i.e. service impersonnation).
More details from: https://www.serfdom.io/docs/internals/security.html
This has been resolved by #138 and related work
From: https://mana.mozilla.org/wiki/display/SECURITY/Nubis#Nubis-#insecuregossipsecret
Insecure Consul gossip authentication allows for impersonation of services
Consul's gossip network is authenticated insecurely and is susceptible to any compromised machine from any product (root is not needed) impersonating any consul load balanced service
Recommendations :
Shared gossip secret should be distributed to Consul clients via a secure path (e.g. KMS)