Add latest changes from gitlab-org/gitlab@master

1 files changed, 78 insertions, 0 deletions

diff --git a/doc/architecture/blueprints/secret_manager/index.md b/doc/architecture/blueprints/secret_manager/index.md
new file mode 100644
index 00000000000..7cc042466e7
--- /dev/null
+++ b/doc/architecture/blueprints/secret_manager/index.md
@@ -0,0 +1,78 @@
+---
+status: proposed
+creation-date: "2023-08-07"
+authors: [ "@alberts-gitlab" ]
+coach: [ "@grzesiek" ]
+approvers: [ "@jocelynjane", "@shampton" ]
+owning-stage: "~devops::verify"
+participating-stages: []
+---
+
+<!-- Blueprints often contain forward-looking statements -->
+<!-- vale gitlab.FutureTense = NO -->
+
+# GitLab Secret Manager
+
+## Summary
+
+GitLab users need a secure and easy-to-use solution to
+store their sensitive credentials that should be kept confidential ("secret").
+GitLab Secrets Manager is the desired system that provides GitLab users
+to meet that need without having to access third party tools.
+
+## Motivation
+
+The current de-facto approach used by many to store a sensitive credential in GitLab is
+using a [Masked Variable](../../../ci/variables/index.md#mask-a-cicd-variable) or a
+[File Variable](../../../ci/variables/index.md#use-file-type-cicd-variables).
+However, data stored in variables (masked or file variables) can be inadvertently exposed even with masking.
+A more secure solution would be to use native integration
+with external secret managers such as HashiCorp Vault or Azure Key Vault.
+
+Integration with external secret managers requires GitLab to maintain the integration
+with the third-party products and to assist customers in troubleshooting configuration issues.
+In addition, customer's engineering teams using these external secret managers
+may need to maintain these systems themselves, adding to the operational burden.
+
+Having a GitLab native secret manager would provide customers a secure method to store and access secrets
+without the overhead of third party tools as well as to leverage the tight integration with other GitLab features.
+
+### Goals
+
+Provide GitLab users with a way to:
+
+- Securely store secrets in GitLab
+- Use the stored secrets in GitLab components (for example, CI Runner)
+- Use the stored secrets in external environments (for example, production infrastructure).
+- Manage access to secrets across a root namespace, subgroups and projects.
+- Seal/unseal secrets vault on demand.
+
+#### Non-functional requirements
+
+- Security
+- Compliance
+- Auditability
+
+### Non-Goals
+
+This blueprint does not cover the following:
+
+- Secrets such as access tokens created within GitLab to allow external resources to access GitLab, e.g personal access tokens.
+
+## Proposal
+
+The proposal is still actively being shaped. It will be updated in subsequent Merge Requests.
+
+## Alternative Solutions
+
+Other solutions we have explored:
+
+- Separating secrets from CI/CD variables as a separate model with limited access, to avoid unintended exposure of the secret.
+- [Secure Files](../../../ci/secure_files/index.md)
+
+## References
+
+The following links provide additional information that may be relevant to secret management concepts.
+
+- [OWASP Secrets Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html)
+- [OWASP Key Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html)