Dynamic Secrets MVC
Problem to solve
This MVC focuses on credential rotation / dynamic secrets / secret variables. Users need secure passwords/tokens, and an additional layer of security is to automatically rotate those credentials so that if any were leaked, they'd be ineffective soon enough anyway.
Secret management is one of the core use cases for Vault. Today, many organizations have credentials hard coded in source code, littered throughout configuration files and configuration management tools, and stored in plaintext in version control, wikis, and shared volumes. Vault provides a central place to store these credentials, ensuring they are encrypted, access is audit logged, and exposed only to authorized clients.
Achieving this centralization is a huge improvement in security posture, but its not the end of the journey. This is because applications don't keep secrets! It turns out, most applications do a worse job keeping secrets than our close friends. Applications frequently log configuration, leaving them in log files or centralized logging systems. Often secrets will be captured in exception tracebacks or crash reports sent to external monitoring systems, or they will be leaked via debugging endpoints and diagnostic pages after hitting an error. The list of ways applications leak secrets goes on, but the point is applications should not be treated as perfectly secure.
This MVC is at its core about adding credential rotation/dynamic secrets features to our bundled Vault.
Many users use Vault for this purpose, which we are planning on bundling with GitLab (gitlab-ce#61548 (closed)). Once this is available, we can build in automatic credential rotation into GitLab's variables (or allow a toggle via gitlab-ce#40720). Using Vault also creates a smaller attack surface.
A good place to start with this automatic rotation is around Kubernetes cluster credentials, internal GitLab database credentials, but we should allow for any kind of secret to be managed in this way.
What does success look like, and how can we measure that?
(If no way to measure success, link to an issue that will implement a way to measure this)