From 321c8ec8aeeb8342f4e0a0e0aae90b5841a41361 Mon Sep 17 00:00:00 2001 From: Sarah Edwards Date: Tue, 11 May 2021 08:05:02 -0700 Subject: [PATCH] add note about environments on self-hosted runners (#19246) Co-authored-by: Martin Lopes --- .../security-hardening-for-github-actions.md | 2 +- content/actions/reference/environments.md | 6 ++++++ 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/content/actions/learn-github-actions/security-hardening-for-github-actions.md b/content/actions/learn-github-actions/security-hardening-for-github-actions.md index f93b07f223..1f1d6d8277 100644 --- a/content/actions/learn-github-actions/security-hardening-for-github-actions.md +++ b/content/actions/learn-github-actions/security-hardening-for-github-actions.md @@ -104,7 +104,7 @@ This list describes the recommended approaches for accessing repository data wit **Self-hosted** runners on {% data variables.product.product_name %} do not have guarantees around running in ephemeral clean virtual machines, and can be persistently compromised by untrusted code in a workflow. -As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories) on {% data variables.product.product_name %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be cautious when using self-hosted runners on private repositories, as anyone who can fork the repository and open a pull request (generally those with read-access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the `GITHUB_TOKEN` which{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}, depending on its settings, can grant {% else %} grants {% endif %}write-access permissions on the repository. +As a result, self-hosted runners should almost [never be used for public repositories](/actions/hosting-your-own-runners/about-self-hosted-runners#self-hosted-runner-security-with-public-repositories) on {% data variables.product.product_name %}, because any user can open pull requests against the repository and compromise the environment. Similarly, be cautious when using self-hosted runners on private repositories, as anyone who can fork the repository and open a pull request (generally those with read-access to the repository) are able to compromise the self-hosted runner environment, including gaining access to secrets and the `GITHUB_TOKEN` which{% if currentVersion == "free-pro-team@latest" or currentVersion ver_gt "enterprise-server@3.1" or currentVersion == "github-ae@next" %}, depending on its settings, can grant {% else %} grants {% endif %}write-access permissions on the repository. Although workflows can control access to environment secrets by using environments and required reviews, these workflows are not run in an isolated environment and are still susceptible to the same risks when run on a self-hosted runner. When a self-hosted runner is defined at the organization or enterprise level, {% data variables.product.product_name %} can schedule workflows from multiple repositories onto the same runner. Consequently, a security compromise of these environments can result in a wide impact. To help reduce the scope of a compromise, you can create boundaries by organizing your self-hosted runners into separate groups. For more information, see "[Managing access to self-hosted runners using groups](/actions/hosting-your-own-runners/managing-access-to-self-hosted-runners-using-groups)." diff --git a/content/actions/reference/environments.md b/content/actions/reference/environments.md index d519fb4f05..176d45cb8d 100644 --- a/content/actions/reference/environments.md +++ b/content/actions/reference/environments.md @@ -48,6 +48,12 @@ Use deployment branches to restrict which branches can deploy to the environment Secrets stored in an environment are only available to workflow jobs that reference the environment. If the environment requires approval, a job cannot access environment secrets until one of the required reviewers approves it. For more information about secrets, see "[Encrypted secrets](/actions/reference/encrypted-secrets)." +{% note %} + +**Note:** Workflows that run on self-hosted runners are not run in an isolated container, even if they use environments. Environment secrets should be treated with the same level as security as repository and organization secrets. For more information, see "[Security hardening for GitHub Actions](/actions/learn-github-actions/security-hardening-for-github-actions#hardening-for-self-hosted-runners)." + +{% endnote %} + ### Creating an environment {% data reusables.github-actions.permissions-statement-environment %}