2 minute read

As a user of Red Hat Advanced Cluster Management (RHACM,) I appreciate how it can prime newly created OpenShift or Kubernetes clusters with standard configuration.

This technote explores the role of RHACM policies in pushing secret store master keys to select clusters in a hybrid setup.

Note that for environments using a single IaaS, something at the IaaS layer is a more secure option, such as Secrets Manager in IBM Cloud and the Kubernetes Secrets Store CSI Driver in AWS EKS.

OpenShift GitOps

As long as the Argo instance is deployed at the cluster scope (the default out-of-the-box configuration when installing the OpenShift GitOps operator,) any cluster configuration can be placed on a Git repository and synchronized into the cluster.

The OpenShift documentation has a good primer on using an Argo CD instance to manage cluster-scoped resources.

There is one limitation when it comes to priming the cluster with secrets since using sealed secrets in a GitOps repo is a questionable concept. I like the idea of using something like the External Secrets operator. However, one still needs to set the master key for its secret store. That is where using a RHACM policy can help.

RHACM Policies

Governance is a central feature in RHACM.

In oversimplified terms, a policy describes what a system administrator wants (or doesn’t want) to have in a cluster.

There are different types of policies, such as requiring that all pods in a namespace have memory requests or that all clusters have an nginx pod running on port 80 in its default namespace.

For the specific purpose of this technote, I wrote a Policy to copy over a master key from a Secret in the hub cluster to a Secret in a managed cluster.

This policy creates a new secret using the copySecretData template function. It creates the secret named main-secret in the namespace cloud-keys of the managed cluster, using as source the values stored in a secret called secret-store-key in the cloud-keys namespace of the hub cluster.

---
apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: secret-store-key
  namespace: cloud-keys
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: ConfigurationPolicy
        metadata:
          name: policy-entkey
        spec:
          object-templates:
            - complianceType: musthave
              objectDefinition:
                apiVersion: v1
                data:  '{{ "{{hub copySecretData \"cloud-keys\" \"secret-store-key\" hub}}" }}'
                kind: Secret
                metadata:
                  name: main-secret
                  namespace: cloud-keys
                type: Opaque
          remediationAction: inform
          severity: low
  remediationAction: enforce

Honorable Mention: Ansible Automation Platform

Using Ansible playbooks suits shops already invested in Ansible Automation Platform.

One can manage all their Ansible Playbooks from a central location, then run those automations on managed clusters.

For shops without prior investment in Ansible, OpenShift GitOps and RHACM policies require less setup and are better aligned with Kubernetes extension APIs.

You May Also Enjoy