In the world of Continuous Integration and Continuous Deployment, Github Actions provide a nifty edge to quickly build end-to-end automation right into the repository. This makes integration of Actions into an organization\u2019s Github repositories pretty straightforward and convenient.<\/p>\n
Github Actions bring velocity to the Software Development Lifecycle. However, if it is swiftly adopted without a well chartered security plan, you may quickly find yourself in muddy\u00a0waters.<\/p>\n
In this blog post, we will discuss some of the key security concerns you should be aware of when using Github Actions. We will also cover the best practices that Salesforce Heroku follows to securely use this exceedingly popular\u00a0product.<\/p>\n
Github Actions<\/a> enables users to run workflows, which are custom automated processes that can be set up in a repository to build, test, package, release, or deploy any code project. These workflows can be executed on Github runners or self-hosted runners.<\/p>\n A workflow file constitutes one or more jobs, and each job is broken down into steps. A step can either execute commands on the runners or utilize an Action to perform a certain task. When building workflows, engineers can write their own custom Actions or utilize the available Actions in the Github Actions marketplace.<\/p>\n The following diagram shows the various components of a workflow\u00a0file:<\/p>\n To understand how a workflow is broken down into jobs and steps, let\u2019s look at a specific scenario.<\/p>\n For every push to a repository, code should be scanned for open source vulnerabilities using Snyk and files should be uploaded to an S3\u00a0bucket<\/p>\n The workflow file for this task may look something like\u00a0this:<\/p>\n A couple of things to\u00a0note:<\/p>\n This workflow will be executed when a push event occurs on any branch of the repository (line\u00a02)<\/em><\/strong>.The workflow has been broken down into two jobs, as they are distinct tasks that do not depend on each other. They will run simultaneously on two isolated containers.Job \u201csnyk_run\u201d (<\/em>line 4<\/em><\/strong>)<\/em> is divided into two steps that run on the same container in the defined order. This permits the steps within a job to share information via the filesystem.The Snyk action used here (line 10)<\/em><\/strong> requires a sensitive token that is stored via Github\u00a0Secrets.The last step in \u201cupload-files\u201d <\/em>(line 32)<\/em><\/strong> <\/em>runs a command to execute a script defined in the repository.<\/p>\n Additional information about Github Actions can be found at https:\/\/docs.github.com\/en\/actions\/learn-github-actions\/understanding-github-actions<\/a><\/p>\n Github Actions is an attractive solution to automate tasks and run tests. Integrating Actions into Github repositories, however, can add to an organization\u2019s risk surface. A few areas of concern are noted in the table\u00a0below:<\/p>\n Third party actions: <\/strong>The third party Action used could potentially run malicious code.Secrets and other sensitive information: <\/strong>Actions may need access to secrets\u200a\u2014\u200athese need to be stored securely and referenced safely.By-products of workflow runs: <\/strong>Access to by-products of a workflow execution (artifacts, caches) should be\u00a0audited.Forked repositories: <\/strong>Access to logs and\/or secrets through forked repositories should be examined.Malicious docker images: <\/strong>Actions could be built on malicious docker\u00a0images.Service Containers:<\/strong> Use of default credentials and access to service containers (redis, postgres) should be\u00a0audited.Runner escape: <\/strong>Malicious code on runners could lead to a potential container breakout.Workflow commands: <\/strong>Commands used in workflows may not function as expected\/documented.Improper configuration of self-hosted runners: <\/strong>Attacks on runners ( remote code execution, privilege escalation) via Actions can lead to lateral movement in an organization\u2019s environment.Third party product vulnerabilities in Actions:<\/strong> Packages used by an Action could have multiple open source vulnerabilities.<\/p>\n As noted above, things can go wrong if Github Actions has been hastily adopted. The best practices we\u2019ll discuss in the following sections help address these concerns.<\/p>\n To minimize risk associated with third party Actions, a standard\/guidance should be developed to define \u201ctrusted\u201d actions. Based on your particular needs and risk appetite the criteria *may*\u00a0include:<\/p>\n GitHub provided standard actions, For Actions falling outside this criteria, it is highly recommended that a security assessment or code review should be conducted before\u00a0use.<\/p>\n Poor practices while writing workflows may quickly compound risk and introduce security gaps. Below are a list of best practices that can help minimize these\u00a0threats:<\/p>\n Use a stable version tag when calling Actions in a workflow file, Sensitive data like access tokens or credentials may be needed during workflow runs. Github Secrets is an built-in secret storage mechanism that can and should be used for these purposes. However, to ensure secrets are safely referenced, here is a list of recommendations to\u00a0follow:<\/p>\n Store all credentials and anything considered sensitive using Github\u00a0Secrets.Github redacts values defined via Secrets from logs; however, do not<\/strong> print secrets to logs deliberately<\/strong>.If a Secret value is greater than 64kb, then users can follow the process defined in https:\/\/help.github.com\/en\/actions\/configuring-and-managing-workflows\/creating-and-storing-encrypted-secrets#limits-for-secrets<\/a> Github provides useful settings that can be utilized at organization or repository level to further minimize risk associated with Actions. These have been described below<\/p>\n To restrict actions used at the repo level: Engineers may want to build their own custom actions to automate tasks. Described below are a few recommendations to keep in mind while doing\u00a0so:<\/p>\n When creating docker container actions, use official or docker certified images. An organization may have Actions enabled in their public Github repositories. Described below are few recommendations to keep in mind with respect to Github Actions in public repositories:<\/p>\n Github Actions is enabled by default in all<\/strong> repositories. Disable Actions in public repositories when not\u00a0requiredIn Settings -> Actions tab, for \u201cWorkflow permissions\u201d<\/em>, select \u201cRead repository contents permission\u201d<\/em>. This ensures least privileges are given to the associated GITHUB_TOKEN Additional best practices can be found at https:\/\/docs.github.com\/en\/actions\/learn-github-actions\/security-hardening-for-github-actions<\/a><\/p>\n To sum up, although Github Actions comes with the promise of conveniently integrating CI\/CD into code repositories, if left unchecked, like most any tool, it brings its own risks. However, incorporating these simple security recommendations enables users to approach Github Actions in a secure\u00a0manner.<\/p>\n https:\/\/docs.github.com\/en\/actions\/learn-github-actions\/understanding-github-actions<\/a>https:\/\/docs.github.com\/en\/actions\/learn-github-actions\/security-hardening-for-github-actions<\/a>https:\/\/medium.com\/cider-sec\/bypassing-required-reviews-using-github-actions-6e1b29135cc7<\/a><\/p>\n Github Actions Security Best Practices<\/a> was originally published in Salesforce Engineering<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n Read More<\/a><\/p>","protected":false},"excerpt":{"rendered":"What can go\u00a0wrong?<\/h3>\n
Best Practices<\/h3>\n
RECOMMENDED THIRD PARTY ACTIONS TO\u00a0USE<\/h4>\n
\u200a\u2014\u200aThese are developed and maintained by GitHub.
\u200a\u2014\u200aA list of these actions can be found at https:\/\/github.com\/actions<\/a>Actions whose creators have been verified by GitHub,
\u200a\u2014\u200aThe blue badge next to the action identifies verified creators.Actions that have been released by trusted vendors of your organization.<\/p>\nWRITING SECURE WORKFLOWS<\/h4>\n
\u200a\u2014\u200aExample: actions\/checkout@v2
\u200a\u2014\u200a<\/em>Alternatively, the commit hash of the stable version can be used, actions\/download-artifact@1de1dea89c32dcb1f37183c96fe85cfe067b682a<\/em>Do not<\/strong> use @master<\/em> tag while calling an Action,
\u200a\u2014\u200aExample, *this is NOT recommended*<\/strong>: actions\/upload-artifact@master<\/em>Use only official or docker certified images when running jobs on docker containers.
\u200a\u2014\u200aAn appropriate security review should be obtained if an image not falling in the aforementioned category is\u00a0needed.When pulling docker images, use the version tag (preferably with the major version),
\u200a\u2014\u200aExample: node:10
\u2014<\/em>version tag is preferred over node:latest.<\/em>Do not<\/strong> use the add::mask<\/em> command to prevent sensitive values from appearing as plaintext in workflow logs.
\u200a\u2014\u200aIf used with environment variables, plaintext values are printed as part of the execution environment into the\u00a0logs.Do not <\/strong>overwrite Github default variables, these have the prefix\u00a0GITHUB_.Do not<\/strong> store sensitive values i.e. access tokens in a file in the cache path.
\u200a\u2014\u200aDo not<\/strong> include <home>\/.docker\/config.json file in the cache, this file may contain unencrypted docker credentials.To create the unique key that identifies a cache, using context data is a common practice
\u200a\u2014\u200aHowever, do not<\/strong> use sensitive values like github.token or github.actor for key generation.
\u200a\u2014\u200aInstead use a hash of a file like requirements.txt<\/em> or package-lock.json<\/em> in combination with system related information like runner.os<\/em>.Do not<\/strong> dump github context data into logs as it might contain sensitive informationArtifacts can be created for sharing information between jobs in the same workflow.
\u200a\u2014\u200aDo not<\/strong> store sensitive information in artifacts as they are available to anyone with access to the repository.
\u200a\u2014\u200aArtifacts are automatically deleted after 90 days. Safely upload them into an s3 bucket if needed beyond that time\u00a0period.Be aware of job execution limits.
\u200a\u2014\u200ahttps:\/\/docs.github.com\/en\/actions\/reference\/usage-limits-billing-and-administration#usage-limits<\/a>Maintain caution when adding outside collaborators\u200a\u2014\u200ausers with read permissions can view logs for workflow failures, view workflow history, as well as search and download logs.
\u2014External collaborators with write access to a repository can modify permissions associated with a GITHUB_TOKEN. This can lead to elevated privileges and possibility for other attacks [3]
\u200a\u2014\u200aIf adding external collaborators is required, follow the principle of least privilege and assign only read permissions for minimal disclosure.<\/p>\nUSING GITHUB SECRETS THE RIGHT\u00a0WAY<\/h4>\n
\u200a\u2014\u200aSecrets stored this way are not<\/strong> automatically redacted by GitHub.
\u200a\u2014\u200aDo not<\/strong> print secrets to logs.
\u200a\u2014\u200aDo not<\/strong> use secrets directly in command line programs.In the workflow file, use secrets as environment or normal variables.
\u200a\u2014\u200aUse quoting when passing them on the command\u00a0line.When a secret is being shared between multiple repositories, they can be added at the Organization level if feasible.
\u200a\u2014\u200aThis avoids duplication and simplifies the rotation\u00a0process.Avoid<\/strong> passing secrets between processes from the command\u00a0line.Establish a credential rolling process and regular\u00a0cadence.<\/p>\nUSEFUL SETTINGS<\/h4>\n
\u200a\u2014\u200aIf use of third party actions is not required, in Settings -> Actions<\/em> tab, enable \u201cAllow local actions only\u201d
\u200a\u2014\u200a<\/em>To use actions created by Github and Github verified creators, in Settings -> Actions<\/em> tab, choose \u201cAllow Select Actions<\/em>\u201d. Enable \u201cAllow actions created by Github\u201d <\/em>and \u201cAllow Marketplace actions by verified creators\u201d<\/em>Forks of a repository, however, do not<\/strong> inherit Secrets, but they can create pull requests on the base branch and access caches. To minimize any information disclosure, if forking is not needed, it can be disabled in the repository under Settings ->\u00a0Options<\/em>To prevent workflow runs from pull requests originating from repository forks, in Settings -> Actions tab, ensure \u201cFork pull request workflows\u201d <\/em>is disabled.<\/strong>To control access of a repository from workflows originating in other repositories, the \u201cAccess\u201d <\/em>setting can be utilized. This is available under Settings -> Actions\u00a0tab.<\/p>\nRECOMMENDATIONS FOR CUSTOM\u00a0ACTIONS<\/h4>\n
\u200a\u2014\u200aUse the version tag (preferably the major version if available).If the custom action is built to interact with internal applications or approved third party applications, store relevant credentials using\u00a0Secrets.Create a separate repository for every action that is to be open\u00a0sourced.https:\/\/help.github.com\/en\/actions\/creating-actions\/about-actions#good-practices-for-release-management<\/a> lists good practices for creating a public\u00a0action.<\/p>\nPUBLIC REPOSITORIES<\/h4>\n
\u200a\u2014\u200aIf \u201cRead and Write permissions\u201d <\/em>are assigned, within a workflow file, an user can add additional permissions to the GITHUB_TOKEN
\u200a\u2014\u200aThis setting can be enabled at the organization levelTo control workflow runs by outside collaborators:
\u200a\u2014\u200aIn Settings -> Actions tab, for \u201cFork pull request workflows from outside collaborators\u201d<\/em> select \u201cRequire approval for all outside collaborators\u201d<\/em><\/p>\nConclusion<\/h3>\n
References<\/h3>\n