Skip to main content

Secret

These tokens are utilized for the auto-creation flow of GitLab runners, allowing them to be registered with the GitLab API. There are three specific Secret types related to this:

Provides access to the GitLab API with the user's permissions. Secret's type: puzl.cloud/gitlab-personal-access-token.

Offers project-specific access for GitLab API operations. Secret's type: puzl.cloud/gitlab-project-access-token.

Grants access for group-level operations within the GitLab API. Secret's type: puzl.cloud/gitlab-group-access-token.

  1. Issue a new personal, group or project access token in your GitLab instance:

    • For GitLab older than v16, you should grant your token the read_api permission scope. We recommend to upgrade your GitLab instance to not grant such broad permissions to Puzl.
    • For GitLab v16 or later, grant your token the create_runner permission scope. This ensures that you don't grant excessively broad access to Puzl.
  2. Secret of any type above must contain a key named token where the GitLab access token is stored. Here is how you apply your GitLab access token to Puzl:

kubectl create secret generic my-gitlab-access-token --type=<Secret_Type_From_Above> --from-literal=token=<Your_GitLab_Access_Token> -n <Your_claimNamespaceRef>

To retrieve all the GitLab access tokens available in a particular Claim Namespace:

kubectl get secrets  -n <Your_Integration_claimNamespaceRef>

Puzl always automatically encrypts all environment variables of your jobs on-the-fly to handle your sensitive data in the most secure way. These encrypted variables are stored in a dedicated Secret of default Kubernetes type Opaque for each job.

When the job is finished, the related Secret with all the environment variables is automatically deleted. Puzl never stores your environment variables out of the job's context.