Aembit provides many different deployment options you can use to deploy Aembit Edge Components in your environment. Each of these options provides similar features and functionality; however, the steps for each of these options are specific to the deployment option you select.
This page describes the process to use the Aembit Edge Agent in GitLab Jobs.
Configure an Access Policy
Section titled “Configure an Access Policy”To configure your Aembit Tenant to support GitLab Jobs as a Client Workload:
-
Configure your Client Workload to identify the Aembit Agent runtime environment with one or more of the following Client Identification options.
-
Configure your Trust Provider type to Gitlab Job ID Token to identify and attest the Aembit Agent runtime environment.
-
Configure your Credential Provider to specify the credential values which you want to be available in the CI runtime environment.
-
Configure your Server Workload to specify the service endpoint host and port which you want to use in the CI runtime environment.
-
Configure your Access Policy and then click Save & Activate.
Configure a custom Resource Set
Section titled “Configure a custom Resource Set”To configure a GitLab Job to work with a custom Resource Set:
-
Open your existing GitLab CI configuration file.
-
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.
-
In your
gitlab-ci.yml
file, either:- update the
AEMBIT_CLIENT_ID
and add theAEMBIT_RESOURCE_SET_ID
environment variables if you moving to a custom Resource Set; or - add both
AEMBIT_CLIENT_ID
andAEMBIT_RESOURCE_SET_ID
environment variables if you are just getting started with enabling your workload to use Aembit.
In the following example, see the
AEMBIT_CLIENT_ID
andAEMBIT_RESOURCE_SET_ID
environment variables in thevariables
section.gitlab-ci.yml variables:AEMBIT_CLIENT_ID: aembit:stack:tenant:identity:gitlab_idtoken:uuidAEMBIT_RESOURCE_SET_ID: bd886157-ba1d-54x86-9f26-3095b0515278 - update the
-
Verify these environment variables match the values in your Resource Set and Trust Provider in your Aembit Tenant.
-
Commit your changes to the GitLab CI configuration file,
.gitlab-ci.yml
.
Deploy the CI Script
Section titled “Deploy the CI Script”-
Retrieve the latest available Aembit Agent Releases.
-
Include Aembit Agent within your CI environment. You do this bundling it within an image or retrieving it dynamically as appropriate for your workload.
-
Configure your CI script to call Aembit Agent with the proper parameters. The following shows an example
gitlab-ci.yml
configuration for a GitLab Job:sample:variables:# Set this to the value of "Edge SDK Client ID" that is provided in the settings of your Trust Provider.AEMBIT_CLIENT_ID: aembit:stack:tenant:identity:gitlab_idtoken:uuid# Add AEMBIT_RESOURCE_SET_ID if using a Custom Resource Set# Example: AEMBIT_RESOURCE_SET_ID: bd886157-ba1d-54x86-9f26-3095b0515278# AEMBIT_RESOURCE_SET_ID: <your_resource_set_id>id_tokens:GITLAB_OIDC_TOKEN:# Set this to the value of "Edge SDK Audience" that is provided in the settings for your Trust Provider.the Audience value from your Trust Provider to this valueaud: https://tenant.id.stack.aembit.ioscript:# Following are samples for OAuth Client Credentials flow, API Key, and Username/Password Credential Provider Types# Please update the --server_workload_host and --server_workload_port values to match your target workloads# Use 'eval' explicitly to ensure the output (for example, 'export TOKEN=...') is executed as shell commands.- eval $(./aembit credentials get --id_token $GITLAB_OIDC_TOKEN --server_workload_host oauth.sample.com --server_workload_port 443)- echo "OAuth Token: $TOKEN"- eval $(./aembit credentials get --id_token $GITLAB_OIDC_TOKEN --server_workload_host apikey.sample.com --server_workload_port 443 --credential_names APIKEY)- echo "API Key Example: $APIKEY"- eval $(./aembit credentials get --id_token $GITLAB_OIDC_TOKEN --server_workload_host password.sample.com --server_workload_port 443 --credential_names USERNAME,PASSWORD)- echo "Username Password Example: $USERNAME -- $PASSWORD"
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:
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.gzcurl -O https://releases.aembit.io/agent/1.24.3328/aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256curl -O https://releases.aembit.io/agent/1.24.3328/aembit_agent_cli_linux_amd64_1.24.3328.tar.gz.sha256.sigImport Aembit's public GPG key from Keybase into
gpg
:Terminal window curl "https://keybase.io/aembit/pgp_keys.asc" | gpg --importVerify 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.sha256If 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.sha256gpg: Signature made Wed Sep 18 10:13:57 2024 PDTgpg: using RSA key EA3D8D2FDAC6BD8137163D00D655E64729BC67D7gpg: 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.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.sha256If
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.
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/arm64/aembit_agent_cli_linux_arm64_1.24.3328.tar.gzcurl -O https://releases.aembit.io/agent/1.24.3328/aembit_agent_cli_linux_arm64_1.24.3328.tar.gz.sha256curl -O https://releases.aembit.io/agent/1.24.3328/aembit_agent_cli_linux_arm64_1.24.3328.tar.gz.sha256.sigImport Aembit's public GPG key from Keybase into
gpg
:Terminal window curl "https://keybase.io/aembit/pgp_keys.asc" | gpg --importVerify Aembit Agent's checksum integrity and authenticity with
gpg
:Terminal window gpg --verify aembit_agent_cli_linux_arm64_1.24.3328.tar.gz.sha256.sig aembit_agent_cli_linux_arm64_1.24.3328.tar.gz.sha256If 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_arm64_1.24.3328.tar.gz.sha256.sig aembit_agent_cli_linux_arm64_1.24.3328.tar.gz.sha256gpg: Signature made Wed Sep 18 10:13:57 2024 PDTgpg: using RSA key EA3D8D2FDAC6BD8137163D00D655E64729BC67D7gpg: 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.Verify the integrity of the Aembit Agent file you downloaded using
shasum
:Terminal window shasum -a 256 aembit_agent_cli_linux_arm64_1.24.3328.tar.gz.sha256If
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.
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/windows/amd64/aembit_agent_cli_windows_amd64_1.24.3328.zipcurl -O https://releases.aembit.io/agent/1.24.3328/aembit_agent_cli_windows_amd64_1.24.3328.zip.sha256curl -O https://releases.aembit.io/agent/1.24.3328/aembit_agent_cli_windows_amd64_1.24.3328.zip.sha256.sigImport Aembit's public GPG key from Keybase into
gpg
:Terminal window curl "https://keybase.io/aembit/pgp_keys.asc" | gpg --importVerify Aembit Agent's checksum integrity and authenticity with
gpg
:Terminal window gpg --verify aembit_agent_cli_windows_amd64_1.24.3328.zip.sha256.sig aembit_agent_cli_windows_amd64_1.24.3328.zip.sha256If 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_windows_amd64_1.24.3328.zip.sha256.sig aembit_agent_cli_windows_amd64_1.24.3328.zip.sha256gpg: Signature made Wed Sep 18 10:13:57 2024 PDTgpg: using RSA key EA3D8D2FDAC6BD8137163D00D655E64729BC67D7gpg: 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.Verify the integrity of the Aembit Agent file you downloaded using
shasum
:Terminal window shasum -a 256 aembit_agent_cli_windows_amd64_1.24.3328.zip.sha256If
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.