Skip to main content


In the Kubernetes ecosystem, a Secret is used to store and manage sensitive information such as passwords, auth tokens, etc.

Puzl utilizes Secret resources to manage crucial data securely: content of all the Secret objects is always stored encrypted. Whether it's for GitLab access tokens, CI/CD environment variables, or Puzl flexible cloud storage credentials, secrets ensure that sensitive data is handled properly.

Puzl has several custom types of Secret resources. All these types are specified below.

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:

Offers project-specific access for GitLab API operations. Secret's type:

Grants access for group-level operations within the GitLab API. Secret's type:

  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 offers flexible cloud storage accessible via the S3 API. If storage is part of a user's subscription level (known as "resource package"), a Secret containing S3 access credentials is automatically generated within the Pipeline Namespace.

The type of this secret is and contains the following keys:

  • HOST: S3 API endpoint for the storage.
  • BUCKET_NAME: The name of the bucket.
  • AWS_ACCESS_KEY_ID: The access key ID for S3 operations.
  • AWS_SECRET_ACCESS_KEY: The secret access key for S3 operations.

Use the following command to retrieve the S3 access details for the given pipeline namespace (notice that all the values are encoded in base64):

kubectl get secrets -n <Your_pipelineNamespaceRef> -o jsonpath='{.items[0].data}'

On Linux-based systems, you can also use this one-liner to decode the Secret's values:

kubectl get secrets -n <Your_pipelineNamespaceRef> --field-selector -o jsonpath='{.items[0].data.HOST}{"\n"}{.items[0].data.BUCKET_NAME}{"\n"}{.items[0].data.AWS_ACCESS_KEY_ID}{"\n"}{.items[0].data.AWS_SECRET_ACCESS_KEY}{"\n"}' | while read -r line; do echo $line | base64 --decode && echo; done

Puzl always automatically encrypts all environment variables of your pipeline 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 pipeline job Pod.

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

For more on the native functionalities of Kubernetes Secrets, please refer to the official Kubernetes documentation on Secrets.