Hybrid Multi-Cloud Dynamic Security Management
This is my study of a real customer use case on dynamic secret management in a multi-cloud environment using Red Hat’s open-source technology.
Join the DZone community and get the full member experience.Join For Free
In my series of articles, I went over the study I did among Red Hat customers that makes the jump towards deploying their workloads on hybrid and multi-cloud environments. These articles are abstractions of the common generic components summarized according to the actual implementations.
To overcome the common obstacles of going hybrid and multi-cloud, such as finding talents with multi-cloud knowledge. Secure and protect across low trust networks or just day-to-day operation across the board. I have identified some solutions from the study, where I will be covering in the series of articles:
Dynamic Security Management
Kubernetes offers its own secret management control, although it’s sufficient for running a single cluster, but when you are trying to manage multiple sets of credentials and secure configurations, especially with the introduction of automated process and continuous delivery practice. We need a better way to securely and centrally manage these data.
How It Works
Check out my previous article on the setup of the hybrid and multi-cloud environment, and if you are interested, another article on getting the GitOps works. But for now, we are going to assume we have a fleet of clusters deployed on top of multiple cloud vendors, and one in the local data center. All the infrastructure is set as code and stored in a source management system. Where our GitOps system constantly coverage the managed clusters with its desired state. In order to set up a secure way to manage credentials and configuration cross clusters, we need two components:
- External Secret management in OpenShift/Kubernetes
- Enable use of external secret management systems (like HashiCorp Vault in this case) to securely add secrets into the OpenShift platform.
- HashiCorp Vault
- Secure centralized store for dynamic infrastructure and application across clusters. For low trust networks between clouds and data centers.
This is how the two components work together to manage secrets in dynamic infrastructure:
- During setup, the token to securely access HashiCorp Vault is stored in Ansible Vault. It is encrypted to protect sensitive content.
- Red Hat Advanced Cluster Management for Kubernetes (RHACM) allows us to have centralized control over the managing clusters. It acquires the token from Ansible Vault during install and distributes it among the clusters.
apiVersion: v1 kind: Secret metadata: name: custom-kubernetes-token data: token: XXXXXXX ... type: Opaque
- To allow the cluster access to the external vault, we need to set up the external secret management (with Helm in this study). OpenShift Gitops is used to deploy the external secret object to a managed cluster.
image: repository: quay.io/xxx/kubernetes-external-secrets tag: 6.4.0-patch1 pullPolicy: Always env: LOG_LEVEL: debug VAULT_ADDR: https://vault-vault.apps.cluster-xxxx.com DEFAULT_VAULT_MOUNT_POINT: kubernetes DEFAULT_VAULT_ROLE: external-secrets CUSTOM_KUBERNETES_TOKEN_PATH: /mnt/token filesFromSecret: token: mountPath: /mnt secret: custom-kubernetes-token
- External secret management fetches secrets from HashiCorp Vault using the token we created in step 2 and constantly watches for updates.
- Secrets are created in each namespace, where applications can use.
This is how to manage dynamic infrastructure secrets in a multi-cluster and cloud environment.
Opinions expressed by DZone contributors are their own.