Github Actions

Enable just-in-time access to your targets through a Github Actions workflow

BastionZero integrates with Github Actions to enable automated just-in-time (JIT) access to named-SSO users and BastionZero service accounts. This allows organizations to permit temporary access to critical targets only when a designated workflow event, such as a deploy, takes place on Github. Otherwise, these targets are inaccessible at all times apart from the authorized Github event.

There are two parts to establish an authorized Github Action:

1. Ensure you have a BastionZero service account set up.

2. Authorize a Github Action as a JIT approver.

Add an authorized Github Action to your organization

1. Authorize a Github Action as a JIT approver. From the zli, use the authorized-action create command to add your authorized Github Action to your BastionZero organization. You will need:

   • The name of your Github organization

   • The name of your Github repository

   • The name of the Github branch

   The command structure follows the format: zli authorized-action create repo:{Github organization name}/{Github repository name}:ref:refs/heads/{Github branch}. For example, zli authorized-action create repo:bastionzero/circle-ci-sa-example:ref:refs/heads/custom-runner allows an action that lives in the Github organization bastionzero, in the Github repository circle-ci-sa-example, in the branch custom-runner to create expiring JIT policies.

2. Create an automatically approved JIT policy for your authorized action to use. If not already created, the JIT policy must select the desired subject (named SSO user or BastionZero service account) that you want your Github Action to create an expiring policy for. The policy must also have the necessary child policies selected for the targets that temporary access should be granted to. Note also that your policy must be set to "automatic approval" for the Github Actions integration to work.

3. Configure your Github Action on Github. Add the lines below at the start of your Github Action. Make sure you adjust the body of the curl to the specific targets you want to request access to. Make sure the Github Action lives on the specified organization/repo/branch combination you have already authorized. You can also use specific target names instead of requesting access to an entire environment by replacing "environmentName": "Default" with "targetNames": "[targetNameA, targetNameB]".

permissions:
 id-token: write # This is required for requesting the JWT
 contents: read  # This is required for actions/checkout
 jobs:
  custom-name-of-your-action:
    runs-on: your-chosen-image
    steps:
    - run: |
         export IDT=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=https://api.bastionzero.com" | jq -r '.value')
         curl -v -H "Authorization: Bearer $IDT" https://cloud.bastionzero.com/api/v2/policies/github-expiring-policy -H "Accept: application/json;" -H "Content-Type: application/json" -d '{"subjectEmail": "[e-mail]","environmentName": "Default","targetUser": {"userName": "root"},"verb": {"type": "Shell"},"clusterUser": "cluster-admin"}'

Example YAML file

Below is an example of what your YAML file may look like.

name: GitHub Actions Example
run-name: ${{ github.actor }} is testing out GitHub Actions 🚀
on: [push]
permissions:
  id-token: write # This is required for requesting the JWT
  contents: read  # This is required for actions/checkout
jobs:
  Explore-GitHub-Actions:
    runs-on: ubuntu-latest
    steps:
      - run: |
          export IDT=$(curl -H "Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=https://api.bastionzero.com" | jq -r '.value')
          curl -v -H "Authorization: Bearer $IDT" https://cloud.bastionzero.com/api/v2/policies/github-expiring-policy -H "Accept: application/json;" -H "Content-Type: application/json" -d '{"subjectEmail": "[e-mail]","targetNames": ["example-cluster-test"],"clusterUser": "cluster-admin"}'

4. Test your setup. Once your Github Action is executed, if all requested targets are valid JIT targets (meaning they are online, the subject does not have access to the target(s) already, and the subjects can gain access to the targets through an automatically approved JIT Policy with the specified target user/verb/cluster user/cluster group), 1-3 expiring policies will be created. If the request includes only Linux targets, a single TargetConnect policy will be created including all requested targets. If the request includes both Linux and Kube targets, a TargetConnect and a Kube Policy will be created, and if the request includes Linux, Kube, and virtual targets, then 3 expiring policies will be created. The response to the request will be True if the request was valid, all targets were eligible JIT targets, and all requested expiring policies were successfully created or False otherwise.

IMPORTANT

If any of the requested targets are not valid JIT targets, the request will fail.