Skip to content
DOCS
User Guide CLI Guide API Guide

Deploy Aembit Edge CLI with GitHub Actions

You can deploy Aembit edge components using multiple methods. Each method provides similar functionality, but the steps differ.

This page describes how to use the Aembit Edge Command-Line Interface (CLI) in GitHub Actions.

Configure an Access Policy

Section titled “Configure an Access Policy”

To configure your Aembit Tenant: Aembit Tenants serve as isolated, dedicated environments within Aembit that provide complete separation of administrative domains and security configurations.Learn more to support GitHub Actions as a Client Workload: Client Workloads represent software applications, scripts, or automated processes that initiate access requests to Server Workloads, operating autonomously without direct user interaction.Learn more:

  1. Configure your Client Workload using one or more of these Client Identification options.

  2. Configure your Trust Provider: Trust Providers validate Client Workload identities through workload attestation, verifying identity claims from the workload's runtime environment rather than relying on pre-shared secrets.Learn more type to GitHub Trust Provider to identify and attest the Aembit Agent runtime environment.

  3. Configure your Credential Provider with the credential values for the Continuous Integration (CI) runtime environment.

  4. Configure your Server Workload with the service endpoint host and port for the CI runtime environment.

  5. Configure your Access Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more referencing the Aembit entities from steps 3 - 6, and then click Save & Activate.

Configure for use with a custom Resource Set

Section titled “Configure for use with a custom Resource Set”

To configure GitHub Actions to work with a custom Resource Set:

  1. Open your existing GitHub Actions configuration file.

  2. Go to your Aembit Tenant, click the Trust Providers link in the left sidebar and locate your GitLab Trust Provider in the Custom Resource Set you are working with.

  3. In your GitHub Actions configuration file, go to the env section for the action step and add both the AEMBIT_CLIENT_ID and AEMBIT_RESOURCE_SET_ID values. The following example shows the AEMBIT_CLIENT_ID and AEMBIT_RESOURCE_SET_ID values in the steps section:

    Example GitHub Actions job
    jobs:
      sample:
        steps:
          - name: Sample
            env:
              AEMBIT_CLIENT_ID: <_your Client ID_>
              AEMBIT_RESOURCE_SET_ID: <_your Resource Set ID_>

  4. Verify both the AEMBIT_CLIENT_ID and AEMBIT_RESOURCE_SET_ID environment variables match the values in your Resource Set and Trust Provider in your Aembit Tenant.

  5. Commit your changes to your GitHub Actions configuration file.

Deploy the CI script

Section titled “Deploy the CI script”

  1. Retrieve the latest Aembit Agent release from the Agent Releases page.

  2. Include the Aembit Agent within your CI environment. Bundle it within an image, or retrieve it dynamically as appropriate for your workload.

  3. Configure your CI job to call the Aembit Agent with the proper parameters. The following example shows a GitHub Actions configuration.

    Example GitHub Actions job
        # The id-token permissions value must be set to write for retrieval of the GitHub OpenID Connect (OIDC) Identity Token
        permissions:
          id-token: write
        ...
        jobs:
          sample:
            steps:
              - name: Sample
                env:
                  # Copy the Client ID value from your Trust Provider to this value
                  AEMBIT_CLIENT_ID: <_your Client ID_>
                  # Add AEMBIT_RESOURCE_SET_ID if using a Custom Resource Set
                  # Example: AEMBIT_RESOURCE_SET_ID: 585677c8-9g2a-7zx8-604b-e02e64af11e4
                  # AEMBIT_RESOURCE_SET_ID: <_your Resource Set ID_>
                run: |
                  # Use 'eval' explicitly to ensure the output (for example, 'export TOKEN=...') is executed as shell commands.
                  # The default environment variable name is TOKEN. Override with the --credential-names option.
                  eval $(./aembit credentials get --server-workload-host oauth.sample.com --server-workload-port 443)
                  echo "Open Authorization (OAuth) Token $TOKEN"

Verify Aembit Agent

Section titled “Verify Aembit Agent”

To verify the Aembit Agent release, follow these steps using the gpg and shasum commands. Select the tab that matches your operating system and architecture:

  1. Download the Aembit Agent release version from the Aembit Agent Releases page along with the matching checksum files.

    Alternatively, you can download these files using curl, swapping out the highlighted release version with the version you're verifying:

    Terminal window
    curl -O https://releases.aembit.io/agent/1.24.3328/linux/amd64/aembit_agent_cli_linux_amd64_1.24.3328.tar.gz
    curl -O https://releases.aembit.io/agent/1.24.3328/aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256
    curl -O https://releases.aembit.io/agent/1.24.3328/aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256.sig

  2. Import Aembit's public GPG key from Keybase into gpg:

    Terminal window
    curl "https://keybase.io/aembit/pgp_keys.asc" | gpg --import

  3. Verify Aembit Agent's checksum integrity and authenticity with gpg:

    Terminal window
    gpg --verify aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256.sig aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256

    If you don't have gpg installed, see Verifying Aembit binary release signatures prerequisites.

    Your output should look similar to the following and include the highlighted line:

    Terminal window
    gpg --verify aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256.sig aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256
    gpg: Signature made Wed Sep 18 10:13:57 2024 PDT
    gpg:                using RSA key EA3D8D2FDAC6BD8137163D00D655E64729BC67D7
    gpg: Good signature from "Aembit, Inc. <keybase@aembit.io>" [unknown]
    ...

    As long as you see Good signature..., you know that the checksum files are valid and authentic.

  4. Verify the integrity of the Aembit Agent file you downloaded using shasum:

    Terminal window
    shasum -a 256 aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256

    If shasum returns a match, you know the file is intact and matches Aembit's original. The long hex string is the SHA256 hash that both your file and the checksums file agree on. No output would mean the checksums don't match.