Secret
GitLab Access Tokens
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:
Personal Access Token
Provides access to the GitLab API with the user's permissions. Secret's type
: puzl.cloud/gitlab-personal-access-token
.
Project Access Token
Offers project-specific access for GitLab API operations. Secret's type
: puzl.cloud/gitlab-project-access-token
.
Group Access Token
Grants access for group-level operations within the GitLab API. Secret's type
: puzl.cloud/gitlab-group-access-token
.
Providing GitLab Access Token to Puzl
-
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.
- For GitLab older than v16, you should grant your token the
-
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>
Environment Variables of Jobs
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.