Skip to main content

Secret

Secret is used to store and manage sensitive information such as passwords, auth tokens, etc.

RunJob utilizes Secret resources to manage crucial data securely: content of all the Secret objects is always stored encrypted.

RunJob has several custom types of Secret resources, which are specified with the related APIs.

RunJob offers flexible cloud storage accessible via the S3®-compatible API. Secret containing S3® access credentials is automatically generated in the namespace, where data volume was claimed.

The type of this secret is puzl.cloud/bucket-access and contains the following keys:

  • HOST: S3®-compatible 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 <Namespace_With_Your_Volume> -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 <Namespace_With_Your_Volume> --field-selector type=puzl.cloud/bucket-access -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

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.

note

Group Access Token must be created with the Maintainer or Owner role to be able to create runners.

  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.