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.
Yes it does exist, see documentation: Secret Detection | GitLab
A quick google helped me find that.
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.
Did you actually read the documentation?
Clearly says and mentions pipelines.
Not only that, and the same link I posted, but to the enable secret detection section: Secret Detection | GitLab
also shows how to add secret detection to the .gitlab-ci.yml file - which is related also to pipelines. There are other ways mentioned in the docs link that was posted.
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.
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.
Thanks for the discussion and issue @tysonkamp!
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.
-James H, GitLab Product Manager, Verify:Pipeline Execution
Thank you for the reply @jheimbuck_gl. Can we close this thread to transfer the discussion to the issue I opened (link to the issue above)?
@tysonkamp I think if you mark that as the solution with a note that discussion is happening in the issue it will work.