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:
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 ```
`
-Dspring.cloud.kubernetes.secrets.name=db-secret
``
-Dspring.cloud.kubernetes.secrets.labels.broker=activemq
-Dspring.cloud.kubernetes.secrets.labels.db=postgresql
`Table 3.1. Properties:
Name | Type | Default | Description |
---|---|---|---|
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