CI/CD Integration

You can easily setup keystone to work with your current CI/CD pipelines using ks ci add. Read on to configure the supported services.

GitHub actions#

To integrate Keystone with GitHub actions you will need a Personal Access Token with repo access. See GitHub’s documentation on Creating a personal access tokens.

Setup#

To setup and send your secrets to your repo type the following command, and choose GitHub CI as a CI service:

ks ci add

You’ll be asked the repo URL, and the Personal Access Token.

Update secrets and files on GitHub repo#

ks ci send --env prod

This will create secrets on GitHub’s side to be used by the Keystone GitHub action.

Add the Keystone GitHub action to your workflow#

In your workflow file, after the checkout action add the following step:

 - name: Load Secrets
        uses: wearedevx/keystone-action
        id: load_secrets
        with:
          keystone_slot_1: ${{ secrets.KEYSTONE_PROD_SLOT_1 }}
          keystone_slot_2: ${{ secrets.KEYSTONE_PROD_SLOT_2 }}
          keystone_slot_3: ${{ secrets.KEYSTONE_PROD_SLOT_3 }}
          keystone_slot_4: ${{ secrets.KEYSTONE_PROD_SLOT_4 }}
          keystone_slot_5: ${{ secrets.KEYSTONE_PROD_SLOT_5 }}

This will load all secrets as environment variables and can be used as such in scripts, or via ${{ env.SECRET_NAME }}.

Files managed by Keystone are written to the job’s container disk and are accessible under the same path you used when adding them to Keystone.

GitLab#

To integrate Keystone with your GitLab pipelines, you will need a Personal Access Token. See GitLab’s documentation on Create a ppersonal access token

Setup#

To setup and send your secrets to your repo type the following command, and choose GitLab CI as a CI service:

ks ci add

You’ll be asked the base URL (defaults to gitlab.com, the project name, and the Personal Access Token.

Update secrets and files on GitHub repo#

ks ci send --env prod

This will create secrets as project variables on GitLab’s side to be use by your pipelines. The environment specified with the --env flag will be used as environment scope. If the environment does not exist on your GitLab server, it will be created.

Using files#

If you manage secret files with Keystone, the ks ci send command will output a before_script configuration to insert in your gitlab-ci.yaml, like:

default:
  before_script:
    - mkdir -p path/to/a/secret/file
    - echo "$SECRET_FILE_VARIABLE" | base64 -d > path/to/a/sercret/file/whispers.txt

This will create the files with their secret content on your gitlab runner

Generic#

For other CI services, it is possible to produce an archive that can be used with a small script.

Setup#

To setup and use this generic solution, type the following command and choose Generic CI as Ci service:

ks ci add

Getting the archive#

ks ci send --env prod

This is will create an archive containing only the secrets and files from the specified environment.

Using the archive#

Upload the archive to your CI runner, and run the following script at the very beginning of your CI job:

# extract and remove the archive
tar -zxvf keystone.tar.gz; rm keystone.tar.gz;
# source the dotenv file
set -o allexport; source .keystone/cache/$ks_environment/.env; set +o allexport;
# move the files in the cache
if [ "$(ls -A .keystone/cache/$ks_environment/files/*)" ]; then
	cp -r .keystone/cache/$ks_environment/files/* ./;
fi

Edit this page on GitHub