Do you store your API keys and other sensitive data with a site that doesn't even have a page discussing their encryption or security practices? Their privacy policy mentions they secure data with SSL protocol...

Who has access to each client's database? Is it audited? Is it encrypted at rest? I'm sure it is, but Config.ly would be wise to add this information to avoid fears.

Also you can store encrypted secrets in Git just fine, there are a number of methods to do so very safely.

Thanks for the feedback. The goal right now is not to store sensitive data in Config.ly - your read API keys will be on your clients - and so in theory anyone who can read that source code can fetch your keys.

> Who has access to each client's database? Is it audited? Is it encrypted at rest? I'm sure it is, but Config.ly would be wise to add this information to avoid fears.

This is great feedback, thank you.

Ohhh, that's such a great idea. I've done that before for TravisCI, now that I remember, it's really slick.

https://docs.travis-ci.com/user/environment-variables/#defin...

Vault/k8s secrets for sensitive data--but you know, it really depends on the context for sensitive data, there isn't a simple answer to say what I've done across the board

Berglas is great in that regard, as you can keep the unique names to the sensitive data in version control, but have the actual values sit in behind an acl in a secure location.

You’re able to guard secretes as need, but keep the audit-ability of version control.

We store the vault paths/fields/versions in git and they're dereferenced outside of git (either directly in the software or in an intermediate deploy step).

Yes! Ansible Vault encrypted. sops is an alternative.