3. Secrets PropertySource

Kubernetes has the notion of [Secrets](https://kubernetes.io/docs/concepts/configuration/secret/) for storing sensitive data such as password, OAuth tokens, etc. This project provides integration with Secrets to make secrets accessible by Spring Boot applications. This feature can be explicitly enabled/disabled using the spring.cloud.kubernetes.secrets.enabled property.

The SecretsPropertySource when enabled will lookup Kubernetes for Secrets from the following sources: 1. reading recursively from secrets mounts 2. named after the application (as defined by spring.application.name) 3. matching some labels

Please note that by default, consuming Secrets via API (points 2 and 3 above) is not enabled for security reasons and it is recommend that containers share secrets via mounted volumes.

If the secrets are found their data is made available to the application.

Example:

Let’s assume that we have a spring boot application named demo that uses properties to read its database configuration. We can create a Kubernetes secret using the following command:

oc create secret generic db-secret --from-literal=username=user --from-literal=password=p455w0rd

This would create the following secret (shown using oc get secrets db-secret -o yaml):

apiVersion: v1
data:
  password: cDQ1NXcwcmQ=
  username: dXNlcg==
kind: Secret
metadata:
  creationTimestamp: 2017-07-04T09:15:57Z
  name: db-secret
  namespace: default
  resourceVersion: "357496"
  selfLink: /api/v1/namespaces/default/secrets/db-secret
  uid: 63c89263-6099-11e7-b3da-76d6186905a8
type: Opaque

Note that the data contains Base64-encoded versions of the literal provided by the create command.

This secret can then be used by your application for example by exporting the secret’s value as environment variables:

apiVersion: v1
kind: Deployment
metadata:
  name: ${project.artifactId}
spec:
   template:
     spec:
       containers:
         - env:
            - name: DB_USERNAME
              valueFrom:
                 secretKeyRef:
                   name: db-secret
                   key: username
            - name: DB_PASSWORD
              valueFrom:
                 secretKeyRef:
                   name: db-secret
                   key: password

You can select the Secrets to consume in a number of ways:

  1. By listing the directories where secrets are mapped: ` -Dspring.cloud.kubernetes.secrets.paths=/etc/secrets/db-secret,etc/secrets/postgresql `

    If you have all the secrets mapped to a common root, you can set them like:
    ```
    -Dspring.cloud.kubernetes.secrets.paths=/etc/secrets
    ```
  2. By setting a named secret: ` -Dspring.cloud.kubernetes.secrets.name=db-secret `
  3. By defining a list of labels: ` -Dspring.cloud.kubernetes.secrets.labels.broker=activemq -Dspring.cloud.kubernetes.secrets.labels.db=postgresql `

Table 3.1. Properties:

NameTypeDefaultDescription

spring.cloud.kubernetes.secrets.enableApi

Boolean

false

Enable/Disable consuming secrets via APIs (examples 2 and 3)

spring.cloud.kubernetes.secrets.enabled

Boolean

true

Enable Secrets PropertySource

spring.cloud.kubernetes.secrets.name

String

${spring.application.name}

Sets the name of the secret to lookup

spring.cloud.kubernetes.secrets.namespace

String

Client namespace

Sets the Kubernetes namespace where to lookup

spring.cloud.kubernetes.secrets.labels

Map

null

Sets the labels used to lookup secrets

spring.cloud.kubernetes.secrets.paths

List

null

Sets the paths where secrets are mounted (example 1)


Notes: - The property spring.cloud.kubernetes.secrets.labels behaves as defined by Map-based binding. - The property spring.cloud.kubernetes.secrets.paths behaves as defined by Collection-based binding. - Access to secrets via API may be restricted for security reasons, the preferred way is to mount secret to the POD.

Example of application using secrets (though it hasn’t been updated to use the new spring-cloud-kubernetes project): spring-boot-camel-config