We need centralized secure storage for infrastructure secrets (passwords, keys, etc). Ideal choice would be a secret storage system, which has plugins for variety of management software we are using.
Problem Statement
Historically, secrets are kept in systems they are used in, because this is the default configuration every system comes with. For example, secrets, used by Jenkins, are kept in Jenkins Credentials internal storage. This complicates secret management (usage monitoring, backups, rotation) and does not allow fine grained access control (as each system has it's own access control, not always flexible enough). Also, when secrets are stored directly in Jenkins Credentials Plugin, they are mixed with other pieces of Jenkins configuration, which makes it hard to establish IaC solution for Jenkins (because that would require to store secrets in code).
This EP is to use Google Secret Manager API (which comes as part of our GCP offering) to store secrets in centralized manner. We can use labels to clarify which system each secret is used in. This is exactly how GCP Secrets Manager Credentials Provider Plugin designed to work: it filters secrets in GCP project by specified label, so all secrets used by Jenkins are clearly visible in Google Secret manager interface.
Additional advantage of using this approach comes up when using Jenkins running in GKE container. In this case, jenkins can use Workload identity to authenticate itself to GCP. I.e., Jenkins installation does not carry any secrets which need to be protected and maintained.
Impact of Action/Inaction
We still can use existing approach (store credentials directly in Jenkins Credentials Plugin).
Suggested Reviewers
[ ] @nieuwsma
[ ] @jeremy-duckworth
[ ] @gbaker-hpe
[ ] @alexanderkingh
Comment Period
Comment period for this proposal shall close on [[May 9, 2022]].
Abstract
We need centralized secure storage for infrastructure secrets (passwords, keys, etc). Ideal choice would be a secret storage system, which has plugins for variety of management software we are using.
Problem Statement
Historically, secrets are kept in systems they are used in, because this is the default configuration every system comes with. For example, secrets, used by Jenkins, are kept in Jenkins Credentials internal storage. This complicates secret management (usage monitoring, backups, rotation) and does not allow fine grained access control (as each system has it's own access control, not always flexible enough). Also, when secrets are stored directly in Jenkins Credentials Plugin, they are mixed with other pieces of Jenkins configuration, which makes it hard to establish IaC solution for Jenkins (because that would require to store secrets in code).
Internal References
External References
Proposed Solution(s)
This EP is to use Google Secret Manager API (which comes as part of our GCP offering) to store secrets in centralized manner. We can use labels to clarify which system each secret is used in. This is exactly how GCP Secrets Manager Credentials Provider Plugin designed to work: it filters secrets in GCP project by specified label, so all secrets used by Jenkins are clearly visible in Google Secret manager interface.
Additional advantage of using this approach comes up when using Jenkins running in GKE container. In this case, jenkins can use Workload identity to authenticate itself to GCP. I.e., Jenkins installation does not carry any secrets which need to be protected and maintained.
Impact of Action/Inaction
We still can use existing approach (store credentials directly in Jenkins Credentials Plugin).
Suggested Reviewers
Comment Period
Comment period for this proposal shall close on [[May 9, 2022]].