This topic explains how to store sensitive data in a Kubernetes secret and retrieve the data from flow variables in an API proxy flow.
There are times when you want to store data for retrieval at runtime—non-expiring data that shouldn't be hard-coded in your API proxy logic. One option is to use the hybrid key-value map (KVM) feature. If you are already using Kubernetes for secret management in a custom vault for sensitive data, you might want to consider using the Kubernetes secret feature described in this topic. Just like with KVM data, you can access the Kubernetes secret data in API proxy flow variables.
What kinds of data can be stored in a Kubernetes secret?
Apigee hybrid limits you to storing the following kinds of data files in a Kubernetes secret. They include:
|File format||Supported file extensions|
|TLS certificate and key files||
Property files are files that contain key/value pairs. For example:
Creating a Kubernetes secret
This section explains how to create a Kubernetes secret for storing sensitive data in the cluster.
- Create the file or files that you wish to store in the Kubernetes secret. The files must be one of the supported formats with the file extensions listed in What kinds of data can be stored in a Kubernetes secret.
- Execute the
kubectl create secret genericcommand. For example:
kubectl -n namespace create secret generic org-env-policy-secret \ --from-file=filepath/prop-file.properties \ --from-file=filepath/key-file.key \ --from-file="filepath/cert-file.pem
- namespace: The Kubernetes namespace where your runtime components are deployed.
- org: Your Apigee organization name.
- env: The name of an environment in your org.
- filepath: The path to the file you wish to include in the secret. You must specify at least one file to include in the secret.
- prop-file: The name of a properties file to include in the secret.
- key-file: The name of a TLS key file to include in the secret.
- cert-file: The name of a TLS certificate file to include in the secret.
You can include one or more files in the secret. For example:
kubectl -n apigee create secret generic myorg-test-policy-secret \ --from-file="$policy_secrets_path"/credential.properties \ --from-file="$policy_secrets_path"/secrets.properties \ --from-file="$policy_secrets_path"/public.key \ --from-file="$policy_secrets_path"/fullchain.pem
After creation, it may take up to 90 seconds for the change to be reflected in all the clusters. The message processors poll for secret changes every 30 seconds. If they detect a change, the cache is updated.
Retrieving data from a secret
Once the secret is created and available (usually about 90 seconds after creation), you can
access the secret data in a flow variable in an API proxy flow in the organization/environment
in which the secret is stored.
For example, assume your secret contains a
with an API key in it, as follows:
You can then retrieve the API key from a flow variable using a policy like Assign Message. For example:
<AssignMessage name="assignvariable-2"> <AssignVariable> <Name>my-apikey</Name> <Ref>private.secret.credential.properties.apikey</Ref> </AssignVariable> </AssignMessage>
The variable name referenced in the
private.secret.credential.properties.apikey, is composed of these parts:
|Variable name part||Description|
||The fixed namespace of the variable. All Kubernetes secrets stored in the hybrid cluster share this namespace.|
||The name of a file stored in the Kubernetes secret.|
||The name of a key stored in a properties file.|
In this example, the Assign Message policy retireves the
stores it in the flow variable
Updating a secret
kubectl does not support updating Kubernetes secrets, you must first
delete the existing secret and recreate it by following the steps in
Creating a Kubernetes secret.