Console
Start free

Storing data in a Kubernetes secret

Version 1.3 (unsupported)keyboard_arrow_down

This topic explains how to store sensitive data in a Kubernetes secret and retrieve the data from flow variables in an API proxy flow.

Introduction

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 *.crt, *.key, and *.pem
Property files *.properties

Property files are files that contain key/value pairs. For example: 

username=admin
password=1f2d1e2e7df

Creating a Kubernetes secret

This section explains how to create a Kubernetes secret for storing sensitive data in the cluster.

  1. 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.
  2. Execute the kubectl create secret generic command. 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

    Where:

    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

    3. 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 *.properties file called credentials.properties with an API key in it, as follows: 

apikey=OrxYQptBMlY1TqmiGLTtyFiaLzzrD25Z

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 Ref element, private.secret.credential.properties.apikey, is composed of these parts:

Variable name part Description
private.secret The fixed namespace of the variable. All Kubernetes secrets stored in the hybrid cluster share this namespace.
credential.properties

The name of a file stored in the Kubernetes secret.

apikey The name of a key stored in a properties file.

In this example, the Assign Message policy retireves the apikey value OrxYQptBMlY1TqmiGLTtyFiaLzzrD25Z and stores it in the flow variable my-apikey.

Updating a secret

Because 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.