3 ms·

That sounds like a lot of work. I don't see any problem with committing secrets into git repositories if a) the git repo is not in the cloud, b) what the secret

by umvi 8y ago

That sounds like a lot of work. I don't see any problem with committing secrets into git repositories if a) the git repo is not in the cloud, b) what the secret is used for is not in the cloud either.

jb3689 8y ago
I don't think it being in the cloud or not makes a difference. Applications that aren't in the cloud can still be broken into. Leaving things in source control just adds another surface for attackers to use to compromise your applications
- umvi 8y ago
  > I don't think it being in the cloud or not makes a difference. Applications that aren't in the cloud can still be broken into. So if the attacker has already broken into our corporate networks and can access the internal applications directly, what's to stop them from just examining the environment variables directly to get the secrets from there? I don't understand the added value of Vault. We have secrets committed to internal GitLab where you need an LDAP account to even view/clone the repo. The secrets are used for internal applications that make calls to external APIs (like a weather service). If the attacker can gain access to the GitLab source, surely it's equally trivial to just examine the environment variables of the internal application itself since the secrets will be in plain text. And if the secrets are not in plain text (i.e. you are passing the secret encrypted), then surely the attacker need only examine the source code (which we've established he has access to) to see how to decrypt the secret from the environment variable. Seems like an impossible chicken and egg problem.
acdha 8y ago
It’s not in the cloud but rather who can access it. If it’s local on your system and you were just going to have the secret sitting in a text file anyway, it’s not much of a change but otherwise you’re increasing that to everyone who can see the repo and making it much harder to remove it. Those are manageable in some cases but if you’re safe from the beginning you never have to spend time on it later or wonder whether you’ve made a mistake in your calculations.

by umvi 8y ago

jb3689 8y ago

I don't think it being in the cloud or not makes a difference. Applications that aren't in the cloud can still be broken into. Leaving things in source control just adds another surface for attackers to use to compromise your applications

umvi 8y ago
> I don't think it being in the cloud or not makes a difference. Applications that aren't in the cloud can still be broken into. So if the attacker has already broken into our corporate networks and can access the internal applications directly, what's to stop them from just examining the environment variables directly to get the secrets from there? I don't understand the added value of Vault. We have secrets committed to internal GitLab where you need an LDAP account to even view/clone the repo. The secrets are used for internal applications that make calls to external APIs (like a weather service). If the attacker can gain access to the GitLab source, surely it's equally trivial to just examine the environment variables of the internal application itself since the secrets will be in plain text. And if the secrets are not in plain text (i.e. you are passing the secret encrypted), then surely the attacker need only examine the source code (which we've established he has access to) to see how to decrypt the secret from the environment variable. Seems like an impossible chicken and egg problem.

acdha 8y ago

It’s not in the cloud but rather who can access it. If it’s local on your system and you were just going to have the secret sitting in a text file anyway, it’s not much of a change but otherwise you’re increasing that to everyone who can see the repo and making it much harder to remove it. Those are manageable in some cases but if you’re safe from the beginning you never have to spend time on it later or wonder whether you’ve made a mistake in your calculations.