Deploy an Operator via GitOps using Advanced Cluster Management

GitOps is a strict discipline: Everything you code or manage should be specified through configuration files in your Git repositories, and applied automatically through CI/CD pipelines. This article shows you how to integrate security policies into GitOps so that they are applied consistently throughout your clusters. Security policies are part of Red Hat Advanced Cluster Management for Kubernetes, a platform that helps developers configure and deploy applications along with other useful services such as metrics. This article also uses Red Hat Advanced Cluster Security for Kubernetes. For background on Red Hat Advanced Cluster Management, read Understanding GitOps with Red Hat Advanced Cluster Management on the Red Hat Hybrid Cloud blog.

Prerequisites

Before beginning the exercise in this article, you'll need to install the following technologies:

• Red Hat OpenShift Container Platform 4.9

• Red Hat Advanced Cluster Management for Kubernetes

• A policies repository to deploy with Red Hat Advanced Cluster Management and Red Hat Advanced Cluster Security

Custom labels can be used to select policies in Red Hat Advanced Cluster Security Management. To take advantage of this feature, create two clusters on the Openshift Container Platform. Assign a label with the name env and the value dev to one cluster, and a label with the name env and the value test to the other.

Deploy the Subscription-Admin policy

The policies repository listed in the prerequisites contains a Subscription-Admin policy. To activate it, in the Red Hat Advanced Cluster Management console, navigate to Governance→Create Policy. Copy and paste the policy-configure-subscription-admin-hub.yaml file from the policies repository into the YAML view. Change the namespace to match the namespace of your cluster, and change the user name (which the file defines as kube:admin) to the username you use to log into Red Hat Advanced Cluster Management. Once you have created the policy, it will be shown in the Governance page in the console (Figure 1).

Install the central policy

Deploy Red Hat Advanced Cluster Security for Kubernetes by navigating to Applications→Create Application→Subscription and entering the information shown in Figure 2:

• The name of your application
• The namespace where you want to install the application
• The URL of its repository
• Your username
• Your access token

Also on the Create an application page, choose Deploy on local cluster (Figure 3).

The application needs a central policy, which must be located in only one of its environments. The policies repository linked to above defines a central policy with the name policy-advanced-cluster-security-central and places it in the test environment using a placement rule in one of the YAML configuration files.

Click Save Application. A successful creation takes you to the resource topology, a visual representation of the resources in your deployed application, including the Subscription-Application (Figure 4).

From the menu on the left, you can choose the Governance tab and see the new Subscription-Admin policy in effect (Figure 5).

Generate the init bundle for the cluster and deploy it via the application

From the test cluster, get the URL of the central endpoint. Enter this URL into your browser and log into the stackrox namespace. (The policies repository assigned the name stackrox because StackRox is the upstream project from which Red Hat Advanced Cluster Security for Kubernetes evolved, but you can use any name of your choice.) Your password will be picked from the secret named central-htpasswd in the namespace.

Navigate to Platform Configuration→Integrations→Cluster Init Bundle→<your_cluster_name>. Click generate→Download kubernetes Secret file. Replace the automatically generated file with the contents of this file.

Now you have to create an application to deploy the generated secret file in both the dev and test clusters. Follow these steps for each cluster:

• Navigate to Applications→Create Application→Subscription.
• Enter the name of the application and the namespace where you want to install it. Choose centralSecrets as the Git path.
• Instead of choosing a local cluster, choose the labels for which the cluster needs to be deployed. As shown in Figure 6, one label has the name env with the value test, and the other has the name env with the value dev.

Installing the secured cluster

Each cluster runs an application. For simplicity, in this section you'll create two identical applications, one for the dev cluster and one for the test cluster. (Another approach would be to create one application and use templates to get the value for the cluster from the secrets, instead of hardcoding the value.)

For the simple approach we'll use here, go through these steps on each cluster:

• Navigate to Applications→Create Application→Subscription.
• Enter the name of the application and the namespace where you want to install it. For the dev cluster, choose secureclusterdeploypolicy_devcluster as the Git path, and for the test cluster, choose secureclusterdeploypolicy_testcluster as the Git path.

Figure 7 shows the values to enter.

Once everything is deployed, you can see the status of your clusters, along with some metrics, in the central server (Figure 8).

Conclusion

This article has shown how configuration files and CI/CD pipelines can be used to manage security policies. The general principles can apply to other processes that you need to automate with GitOps.