Answers: <p>Developers or even admins of your GitHub repository wouldn't be able to see secrets configured there by default. Even if you debug GitHub Actions workflows and accidentally log secrets, GitHub would mark them with ***.</p>
  
  <p>So the only attack vector I can think of is highly deliberate and it would require modifying GitHub Actions workflow code and egressing the secret outside to some pre-configured recipient on the Internet.</p>
  
  <p>If you're worried about such attack vector beyond regular code reviews, you may try exploring CODEOWNERS as a way to protect .github directory - <a href="https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners" rel="nofollow noreferrer">https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners</a>. </p>
  
Answers: CC BY-SA 4.0
Answers: 2020-06-03T01:20:32.703Z
Answers: 2020-06-03T01:20:32.703Z
Answers: taleodor
Body: <p>I'm writing a CI pipeline using GitHub Actions.</p>
  
  <p>The pipeline will build a Docker image, which it will then push to our Docker repository (<a href="https://github.com/marketplace/actions/aws-ecr" rel="nofollow noreferrer">AWS ECR</a>).</p>
  
  <p>In order to talk to ECR, we'll need to provide a secret (and some other details).</p>
  
  <p>That secret we'll be pulling from <a href="https://github.com/marketplace/actions/vault-secrets#authentication-method" rel="nofollow noreferrer">Hashicorp Vault</a>... though that itself requires a secret in order to access it, so to some extent we're just offsetting the problem.</p>
  
  <p>The pipeline's code is in the same repository as the code for which it is run (to which our developers have access); though we can hold some actions called by this code in a separate repository (to which only our DevOps team have access) if needed.</p>
  
  <p>Whilst we trust our developers, it's generally good practice to keep things locked down where possible.  As such, is there any way we can set things up such that developers can amend the pipeline without being able to (deliberately or otherwise) expose these secrets?  Are there any best practices around this sort of thing?</p>
  
Tags: <security><github><hashicorp-vault><secret-management><aws-ecr>
Title: How to protect secrets whilst enabling the ability to amend a pipeline
UserDisplayName: JohnLBevan
ThreadText: # How to protect secrets whilst enabling the ability to amend a pipeline
  
  (Asked by: username_0 on 2020-06-01)
  
  I'm writing a CI pipeline using GitHub Actions.
  
  The pipeline will build a Docker image, which it will then push to our Docker repository ([AWS ECR](https://github.com/marketplace/actions/aws-ecr)).
  
  In order to talk to ECR, we'll need to provide a secret (and some other details).
  
  That secret we'll be pulling from [Hashicorp Vault](https://github.com/marketplace/actions/vault-secrets#authentication-method)... though that itself requires a secret in order to access it, so to some extent we're just offsetting the problem.
  
  The pipeline's code is in the same repository as the code for which it is run (to which our developers have access); though we can hold some actions called by this code in a separate repository (to which only our DevOps team have access) if needed.
  
  Whilst we trust our developers, it's generally good practice to keep things locked down where possible. As such, is there any way we can set things up such that developers can amend the pipeline without being able to (deliberately or otherwise) expose these secrets? Are there any best practices around this sort of thing?
  
  **Tags:** security, github, hashicorp-vault, secret-management, aws-ecr
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-06-03. Score: 1 | Accepted answer
  
  Developers or even admins of your GitHub repository wouldn't be able to see secrets configured there by default. Even if you debug GitHub Actions workflows and accidentally log secrets, GitHub would mark them with \*\*\*.
  
  So the only attack vector I can think of is highly deliberate and it would require modifying GitHub Actions workflow code and egressing the secret outside to some pre-configured recipient on the Internet.
  
  If you're worried about such attack vector beyond regular code reviews, you may try exploring CODEOWNERS as a way to protect .github directory - <https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners>.
  
  
  ---
  
  