In light of the recent CircleCI hack, they (CCI) deployed a script/repo that will dump all secret names that exist in an org. This is help handle a situation where teams would need to rotate basically all secrets re compromised.
It would be good practice for GitLab to have the same. If this isn’t the right forum to draw attention to this can someone recommend where the request could be made? I’m relatively new to GL. Also, if the solution exists can someone point me there? Thanks in advance.
I’m not interested in secrets accidentally committed to a repo, I’m interested in secrets that are part of the pipeline for it to function. These are the items that would need to be invalidated and rotated in the event of a GitLab breach.
Ian I think what Tyson is looking for is an automated way to identify ci/cd variables being used in the event gitlab is ever compromised as they could be used to store pipeline secrets. I don’t know if there is a way to do this via the api but there is probably a way to perform a database query to at least identify the variable names. The rotation aspect I don’t know how you would do that. My recommendation would be to use a proper secrets vaulting service and then only store the secret zero (secret to retrieve the secrets) in gitlab variables. This would centralize your storage and usually allows for more management capabilities like rotation etc…
Jeymz this is exactly what I was trying to articulate, thank you. As far as rotation goes, we can handle that but under the pressure of a CircleCI style breach at GitLab, we’ll need to go rotate everything asap and know we got them all.
First order of business is to perform some hygeine on what is in GitLab to make sure we’re not messing around with potentially outdated and unnecessary secrets leftover from dev cycles.
Second order is to conduct a review of what is left for best practices e.g. sufficient key lengths.
Third order is some type of “dry-fire” exercise where we’re at least verbally discussing how we’ll handle a breach WHEN it happens.
The API does allow for this but I was hoping that GitLab (being the subject matter expert about their own API) would provide and maintain a mechanism like CircleCI did. Granted it took a breach for CCI to do this.
The API is the best way to retrieve any variables or tokens stored in GitLab that may need to be rotated today. Project and Group Variables, Project and Group Access Tokens and Deploy tokens are some of the things a tool like this may want to list but there may be more I am missing. I’ll add that list to the issue.
We do recommend that customers use an external secret store for managing secrets and NOT storing them within GitLab variables as masking is “best-effort” if a variable is accidentally revealed.
My team is starting work on a feature to detect and mask some secrets in the Job Logs similar to the functionality described for finding secrets in code. You can see how we are thinking about the MVC and later possible work in the epic.