Secure method for storing application credentials? #2217
Comments
@benmccann certainly worth a look. I'd love to improve security of how we handle application secrets. We're big on incorporating tools/approaches that work for others. |
When you create a new config today, it creates a new release. How is that handled? Is that metadata that is stored in etcd or some datastore? Or does it build a new docker image? I'm not really sure what happens behind the scenes |
@benmccann that information is stored in the database and is tacked onto the docker images within the registry. etcd never sees the config. See https://github.com/deis/deis/blob/master/controller/api/models.py#L557 |
From my perspective crypt looks like a mini fork of confd with keyring support. If this is a good practice for us, we should investigate how we can contribute upstream to confd and utilize this for things like the router's SSL certificate/keys. Application config is already locked away in the database so it should be secure unless an external user gets access to the cluster (which at that point there's a lot more at stake than app information). |
I've been trying to follow what other projects are doing for this. Kubernetes recently started to make some really good progress here and has a good design doc. I think what they're doing looks like a pretty good solution |
For Deis, we bake the security credentials directly into the docker image when a new release is created. That way, the user does not need to source a file inside the container, and the container does not need to fetch them from the controller or access etcd to retrieve values. The only way external users can access those secrets are by accessing the container directly. Eventually we can switch this out for something like moby/moby#10310 but this works for us at the moment. The relevant code: https://github.com/deis/deis/blob/master/controller/registry/private.py#L60-L64 |
@benmccann does this help you understand how application credentials are stored or would a specification help clarify things? Not quite sure what's the actionable item for this issue is, considering that we already store application credentials securely. |
I'll close this since there's no specific ask at the moment. I was just curious how Deis handles this |
Would it make sense to use crypt for storing application credentials? Not sure what Deis is doing now, but it seemed like potentially a neat way to have that part managed by an open source component that can be shared by other projects as well such that it's more standardized and less unique to Deis.
The text was updated successfully, but these errors were encountered: