<p>we are starting with Kubernetes and wondering how other projects manage Kubernetes secrets:</p>

<ul>
<li>Since Kubernetes secrets values are just base64 encoded, it's not recommended to commit the secrets into source control</li>
<li>If not committing to source control, it should be kept in some central place somewhere else, otherwise there's no single source of truth. If it's stored in some other places (.e.g. Hashicorp Vault), how's the integration with CI? Does the CI get values from Vault, create secrets resource on demand in Kubernetes?</li>
<li>Another approach is probably to have a dedicated team to handle infrastructure and only that team knows and manages secrets. But if this team can potentially become a bottleneck if number of projects are large</li>
</ul>

Phuong Nguyen
<blockquote>
  <p>how other projects manage Kubernetes secrets</p>
</blockquote>

<p>Since they are not (at least not yet) proper secrets (base64 encoded), we treat them to separate restricted access git repository.</p>

<p>Most of our projects have code repository (with non-secret related manifests such as deployments and services as part of CI/CD pipeline) and separate manifest repository (holding namespaces, shared database inits, secrets and more or less anything that is either one-time init separate from CI/CD, requires additional permission to implement or that should be restricted in any other way such as secrets).</p>

<p>With that being said, although regular developer doesn't have access to restricted repository, special care must be given to CI/CD pipelines since even if you secure secrets, they are known (and can be displayed/misused) during CI/CD stage, so that can be weak security spot there. We mitigate that by having one of our DevOps supervise and approve (protected branches) any change to CI/CD pipeline in much the same manner that senior lead is supervising code changes to be deployed to production environment.</p>

<p>Note that this is highly dependent on project volume and staffing, as well as actual project needs in term of security/development pressure/infrastructure integration.</p>
