1. Context
Secret managers securely store sensitive data like API keys and passwords, preventing hardcoded secrets and reducing exposure risks. They provide encrypted storage, access control, and automated rotation, ensuring secure management of credentials across distributed applications. It is crucial, expecially in could environments, to be able to use such services.
2. Prerequisites
A camel integration to be deployed on OpenShift.
External Secrets Operator installed in your OCP Cluster namespace.
3. Goal
Provide a configuration example to retrieve AWS Secrets Manager Secrets through the External Secrets Operator feature.
4. Configuration
First of all all of the following could be supported by simply adding the camel-kubernetes component to your classpath.
You can create a secret through AWS CLI with the following command:
aws secretsmanager create-secret –name authsecdb –secret-string \file://secret.json
Where the content of secret.json could be something like:
{
"username": "postgresadmin",
"password": "xxxx",
"host": "host"
}The secret name will be authsecdb and the secret fields will be username, password and host.
The Spring Boot and Quarkus runtime have the starter and the extension related to Kubernetes in their catalogs.
The usage of the External Secrets Operator allows to bridge the AWS Secrets Manager Secret with a Kubernetes Secret Resource.
This means, there won’t be the need to setting up the refresh features on AWS infra, but instead we’re going to leverage the Refresh feature Camel Kubernetes Component for secrets.
External Secrets Operator will, indeed, sync the Kubernetes secret value with the one coming from the vault on a period basis.
Camel Kubernetes component will notice the Kubernetes secret update and it will refresh the Camel context.
This configuration could be seen on OCP by following the Camel on OCP Best Practices repository, in particular, the External Secrets Operator section. You can follow the example for both the runtimes supported by Red Hat Build of Apache Camel: