Aembit Credentials (GitHub Action)

Overview

This action retrieves temporary credentials from Aembit for use in your GitHub workflows. It enables secure, secretless access to external systems like cloud providers or APIs by dynamically fetching scoped credentials at runtime. This helps improves security within CI/CD pipelines.

Requirements

Workflow Permissions

Important

This Action retrieves an OIDC token for your workflow from GitHub to attest its identity with Aembit. Your workflow must have the following permission for it to work.

permissions:
  id-token: write

Aembit Configuration

In Aembit, your Client Workload must use the GitHub ID Token Repository identifier, in the format org-name/repository-name. We plan to add support for the GitHub ID Token Subject identifier in future releases.

The Trust Provider in your Access Policy must be of type GitHub Action ID Token, using a repository Match Rule with a value that includes the org/repository of your workflow. Other Match Rule attributes may work but have not been tested.

Usage

- uses: Aembit/get-credentials@v1
  id: step-id # This is required as output of this step is passed to the next step(s).
  with:
    # Aembit Edge SDK Client ID. 
    # The unique identifier for your GitHub Trust Provider in Aembit. 
    # You can find it by logging into your Aembit tenant, navigating to Trust Providers, selecting your GitHub Trust Provider, and copying the Edge SDK Client ID. 
    # This is a required field.
    client-id: ''
    
    # Specifies the type of credential to retrieve from Aembit.
    # Valid values are: ApiKey, UsernamePassword, OAuthToken, GoogleWorkloadIdentityFederation, AwsStsFederation
    # This is a required field.
    credential-type: ''

    # Server Workload - Service Endpoint Host
    # Used to access server workload which in turn is used to access credentials. 
    # You can find it by logging into your Aembit tenant, navigating to Server Workloads, selecting your desired Server Workload, and copying the Service Endpoint Host.
    server-host: ''
    
    # Server Workload - Service Endpoint Port
    # Used to access server workload which in turn is used to access credentials. 
    # You can find it by logging into your Aembit tenant, navigating to Server Workloads, selecting your desired Server Workload, and copying the Service Endpoint Port.
    # Default: 443
    server-port: 443

Outputs

The outputs available depend on the credential-type specified:

ApiKey

outputs:
    # API key credential
    # Usage: ${{ steps.step-id.outputs.api-key }}
    api-key: '****'

UsernamePassword

outputs:
    # Username credential
    # Usage: ${{ steps.step-id.outputs.username }}
    username: '****'

    # Password credential
    # Usage: ${{ steps.step-id.outputs.password }}
    password: '****'

OAuthToken

outputs:
    # OAuth token credential
    # Usage: ${{ steps.step-id.outputs.token }}
    token: '****'

GoogleWorkloadIdentityFederation

outputs:
    # Google Workload Identity Federation token
    # Usage: ${{ steps.step-id.outputs.token }}
    token: '****'

AwsStsFederation

outputs:
    # AWS Access Key ID
    # Usage: ${{ steps.step-id.outputs.aws-access-key-id }}
    aws-access-key-id: '****'

    # AWS Secret Access Key
    # Usage: ${{ steps.step-id.outputs.aws-secret-access-key }}
    aws-secret-access-key: '****'

    # AWS Session Token
    # Usage: ${{ steps.step-id.outputs.aws-session-token }}
    aws-session-token: '****'

Note

All the outputs generated by this action are GitHub masked secrets.

Troubleshooting

If you are getting the error

Error: Invalid or currently unsupported credential type: Unknown

then Aembit cannot connect your GitHub workflow with an access policy that identifies a credential to return. Some things to double-check in your configuration are:

• the Client Workload in Aembit has the right org/repository identifier for your workflow
• the Trust Provider in Aembit allows the org/repository for your workflow
• the credential-type value in the Action config matches the type of Credential Provider in your Access Policy
• the server-host and server-port values in the Action config match the Server Workload in your Access Policy