<p>You need to provide more information about the technology stack.</p>
<p>In a nutshell, you would mix the responsibilities of the host, taking care for the gitlab runnner + credential store is not a good design practice. If the host goes down, you are loosing 2 essential services, instead of just one. Most likely you would have other consumers of the store. Also this is breaking the single responsibility principle.</p>
<p>I could tell you from own experience is that we use 'AWS Parameter store' for that  ( H/A and detached service ). The secrets are consumed by a helm chart - <a href="https://github.com/cmattoon/aws-ssm" rel="nofollow noreferrer">https://github.com/cmattoon/aws-ssm</a> and injected into the cluster as configurations. After that each interested party could use whatever it wants.</p>

CC BY-SA 4.0
2020-11-18T10:45:23.037Z
2020-11-18T10:45:23.037Z
Recoba20
<p>Imagine you have a GitLab Docker runner which you would like to pass credentials from a credential store. That is the CI/CD variable just designates the credentials profile name.</p>
<p>Is there a way to connect Docker containers to host's credential store?</p>

<docker><gitlab><security><credentials>
Host credential manager and Docker runners
Ta Mu
# Host credential manager and Docker runners

(Asked by: username_0 on 2020-11-06)

Imagine you have a GitLab Docker runner which you would like to pass credentials from a credential store. That is the CI/CD variable just designates the credentials profile name.

Is there a way to connect Docker containers to host's credential store?

**Tags:** docker, gitlab, security, credentials


---

## 1 answers

### Answer by username_1 on 2020-11-18. Score: 1

You need to provide more information about the technology stack.

In a nutshell, you would mix the responsibilities of the host, taking care for the gitlab runnner + credential store is not a good design practice. If the host goes down, you are loosing 2 essential services, instead of just one. Most likely you would have other consumers of the store. Also this is breaking the single responsibility principle.

I could tell you from own experience is that we use 'AWS Parameter store' for that ( H/A and detached service ). The secrets are consumed by a helm chart - <https://github.com/cmattoon/aws-ssm> and injected into the cluster as configurations. After that each interested party could use whatever it wants.


---

