CODEWITHSUNDEEP
yamlgithub-actionsworkflowaws-secrets-manager
Danish Sattar
Danish Sattar

Reputation: 89

Github Secrets are not really secured, how to secure secrets permanently

I don't know why Github secrets are really called secrets, because it can be printed out by any person working in organization with push access, i.e. they create branch use below trick to print secret and then delete the branch, and with snap of fingers any employee can take out secrets.

If there is optimal solution, kindly guide me to permanently secure my github action secrets.

 steps:
      - name: 'Checkout'
        uses: actions/checkout@master
      - name: 'Print secrets'
        run: |
            echo ${{ secrets.SOME_SECRET }} | sed 's/./& /g'

Upvotes: 6

Views: 5782

Answers (2)

GuiFalourd
GuiFalourd

Reputation: 22980

@rethab answer is great, I'll just add the answer I got from the Github Support after I contacted them for a similar issue.

Thank you for writing to GitHub Support.

Please note that it is not expected behavior that GitHub will redact every possible obfuscation of the secrets from the logs.

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#using-secrets

To help prevent accidental disclosure, GitHub uses a mechanism that attempts to redact any secrets that appear in run logs. This redaction looks for exact matches of any configured secrets, as well as common encodings of the values, such as Base64. However, because there are multiple ways a secret value can be transformed, this redaction is not guaranteed.

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions#exfiltrating-data-from-a-runner

To help prevent accidental secret disclosure, GitHub Actions automatically redact secrets printed to the log, but this is not a true security boundary because secrets can be intentionally sent to the log. For example, obfuscated secrets can be exfiltrated using echo ${SOME_SECRET:0:4}; echo ${SOME_SECRET:4:200};

Notice that in this case, what is being printed in the logs is NOT the secret that is stored in the repository but an obfuscation of it. Additionally, any user with Write access will be able to access secrets without needing to print them in the logs. They can run arbitrary commands in the workflows to send the secrets over HTTP or even store the secrets as workflows artifacts and download the artifacts.

You can read more about security hardening for GitHub Actions below:

https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

Upvotes: 3

rethab
rethab

Reputation: 8413

First off, GitHub has an article on Security hardening for actions, which contains some general recommendations.

In general, you want to distinguish between public and internal/private repositories.

Most of my following answer is on internal/private repositories, but if you're concerned about public repositories: Keep in mind that actions are not run on PRs from third parties until they are approved.

For internal/private repositories, you're going to have to trust your colleagues with some secrets. Going through the hassle of guarding all secrets to the extent that they can't be "extracted" by a colleagues is probably not worth the effort. And at that point, you probably also have to ask yourself what damage a malicious employee could do even without knowing these secrets (perhaps they have inside knowledge of your business, they work in IT so they might be able to put your services offline, etc). So you're going to have to trust them to some extent.

Some measures to limit the damage a malicious colleague could do:

Environment Secrets

You can create a secret for an environment and protect the environment.

For example, assume you want to prevent colleagues from taking your production secrets and deploy from their computers instead of going through GitHub actions.

You could create a job like the following:

jobs:
  prod:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - run: ./deploy.sh --keys ${{ secrets.PROD_SECRET }}

Steps:

  • Configure the secret PROD_SECRET as an environment secret for production
  • Create the environment production and setup protection rules
    • If you really want to be sure nobody does something you don't like, you can set yourself as a reviewer and then manually approve every deployment

Codeowners

You could use codeowners and protect the files in .github/workflows. more about codeowners

OIDC and reusable workflows

If you're deploying to some cloud environment, you should probably use OpenID Connect. That, combined with reusable workflows, can give you an additional layer of security: You can specify which workflow is allowed to deploy to production.

Upvotes: 4

Related Questions