If your pipeline needs to access sensitive information such as passwords, tokens, or keys, you need a way to securely insert these secrets at runtime, without including them directly in your pipeline config. You also need a way to manage these secrets and update them without needing to update automation scripts.
In JFrog Pipelines, secrets are stored as properties in Integrations, where all of the integration's properties are stored in encrypted vault storage. Pipelines provides two ways to use integrations to insert secrets into your steps:
Standard integrations
Generic integration
Using Standard Integrations
Pipelines provides a set of standard integrations that help link your resources and worfklows to specific external services such as GitHub, Slack, or Artifactory. A Pipelines admin enters the access secrets for these services (such as tokens or login credentials) when configuring these integrations. These secrets are stored in the secure vault.
In general, you are not likely to need direct access to these integration's secrets. When you define a resource, you will specify the integration in the integrations block and your steps will connect to the service through the resource. Or your steps will access the service through the integration directly, rather than through a resource. In this way, secrets are securely maintained independently of the pipeline script.
However, if you need to directly access a secret from the integration, you may do so through the environment variable for that integration.
For example, if you have an AWS Keys Integration called myAWSKeys, you can reference the Access Key property through an environment variable:
steps:
- name: spoil_secret
type: Bash
configuration:
integrations:
- name: myAWSKeys
execution:
onExecute:
- printenv int_myAWSKeys_accessKeyId
Using the Generic Integration
A Generic Integration is an integration type that is not for linking to a specific service, but exists exclusively to securely store key-value pairs of information. This is appropriate for storing secrets such as tokens or passwords for retrieval by a step.
When you add this integration to a step, all key-value pairs are made available as environment variables in the form:
int_<integration-name>_<key>
For example, a Pipelines admin can define a Generic integration with the following entries:
Name:
myCredentialsCustom Environment Variables:
Key:
usernameValue:
janedoeKey:
passwordValue:
nAm30fMyp3t
When myCredentials is specified in a step's integrations block, the key-value pairs stored there can then accessed in the step as environment variables:
pipelines:
- name: generic_integration_example
steps:
- name: step_1
type: Bash
configuration:
integrations:
- name: myCredentials
execution:
onExecute:
- printenv int_myCredentials_username
- printenv int_myCredentials_password