Open tinnightcap opened 8 years ago
The solution is to properly implement ACLs. That work is being tracked in: https://github.com/nubisproject/nubis-consul/issues/85
Since the work in #138, the platform secrets are segmented out from the application secrets. It's not a complete solution, but it's a start.
The remaining tasks to review this are :
A mitigating factor to this is that JD reports that current products which use nubis don't have multiple tiers (meaning there are no current products using nubis with different types of instances which use different secrets, like a webserver and db server)
Consul's method of controlling access to the secrets which it stores is by requiring that clients requesting secrets authenticate themselves with a x509 keypair signed request. The request must be signed by a x509 keypair which has been signed by a predefined certificate authority. The consul server has the public key of this certificate authority set so that only clients with certs signed by that CA can request secrets.
This design doesn't allow for differing security levels within a product. Since all hosts have access to all secrets for the product, the weakest link (perhaps with the greatest attack surface because it's a webserver) is the maximum security all that product's instances can obtain. Because staging and production are in different VPCs and security groups control access to the Consul API, staging instances can not access production secrets.
A planned mitigation for this issue is to enable jenkins to provision an ACL token from Consul and inject it into a stack via CloudFormation and then into the ec2 instance via user_data
This security control will reduce this risk but it will remain significant. In a model with this security control, the ACL token and by extension all secrets which that instance has access to (or all secrets if there is no ACL differentiation) are available to all users with the ability to read CloudFormation stack outputs or to read instance user_data .