Secret
Overview
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.
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>
Cloud Storage S3 API credentials
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 puzl.cloud/bucket-access
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 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
Environment Variables of Pipeline Jobs
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.
Further Reading
For more on the native functionalities of Kubernetes Secrets
, please refer to the official Kubernetes documentation on Secrets.