Red Hat Advanced Cluster Security with OpenShift Pipelines and Slack Integration

Summary

This article describes the installation of Red Hat Advanced Cluster Security (RHACS) using the Operator. It also covers the integration of Tekton Pipelines for the deployment of two different containers and the configuration of a Slack notification. A special feature here is that the installation and configuration is largely automated by scripts and can thus be automated and reproduced. In addition, the installation and configuration provide an architectural picture and the functionality of Advanced Cluster Security. Please use the this GitHub Repo in parallel while reading the blog post. Here you will find all the resources and scripts described in this post.

Use Case

In this demo example, we want to prevent containers that do not meet all security requirements from being deployed. If an attempt is made to deploy a non-compliant container, users should be notified. Specifically, we want to prevent an UBI image from being deployed in version 7 and point out that version 8 should be used. As soon as a version 8 image is deployed, our pipeline runs successfully. However, if an attempt is made to deploy a version 7 image, the pipeline fails and a Slack notification is sent. The configuration of the Slack notification and the set of rules to be applied is managed by Red Hat Advanced Cluster Security. The deployment is triggered by OpenShift pipelines.

Prerequisites

There are a few prerequisites for rebuilding this demo. Among other things, this includes a running OpenShift 4 cluster. Furthermore, the following CLI tools are used in the scripts and commands:

• oc
• roxctl
• curl
• jq

Installation of Red Hat Advanced Cluster Security

Advanced Cluster Security can generally be carried out in two different ways. On the one hand, it can be installed via the GUI in the Operator Hub. For this post, however, we will use OpenShift’s Command Line Interface. We will apply the necessary Kubernetes resources. For this purpose, a few files are prepared in this GitHub repository, which are located in the acs-install folder.

Subscription

The Kubernetes Resource 01_subscription.yaml is used to install the operator. It is the CustomResource that connects an Operator to a CatalogSource. Subscriptions describe which channel of an operator package should be subscribed to and whether updates should be performed automatically or manually.

Namespace

The file 02_project.yaml is responsible for creating a new namespace for the Advanced Cluster Security Deployments. It makes sense to manage all resources in one namespace. Among other things, namespaces can help to structure permissions and workloads.

Advanced Cluster Security – Central

The Central component is responsible for the administration of Advanced Cluster Security and forms the core. With the application of 03_central.yaml, the custom resource of type Central is created in the namespace stackrox. This leads to the operator deploying and configuring the Central components in OpenShift.  

Init Bundle

After installing Central, a bundle for initializing Secured Clusters can be downloaded. A script can be found in the Github repository under the file 04_create-init-bundle-sh. The init bundle is downloaded with the Advanced Cluster Security CLI tool roxctl. To do this, the password for the Central and also the URL at which the Central can be reached are loaded via the OpenShift CLI command and then used in the roxctl command to authenticate to the Central server. After exporting the init bundle, it is applied in the OpenShift cluster.

Secured Cluster

In this step, the SecuredCluster custom resource is applied to the OpenShift cluster. In contrast to the Central component, a Secured Cluster contains all deployments and resources necessary to control a Kubernetes cluster. Roughly speaking, the Central manages the Stackrox database consistently for all connected Secured Clusters. A Secured Cluster is then responsible for adhering to the rules configured in the Central. Further information on the architecture of Advanced Cluster Security can be found in the documentation. You should definitely take a look here if you have not yet dealt with the architecture of Advanced Cluster Security. The resource is located in 05_secured-cluster.yaml.

Configuration of Advanced Cluster Security

In this part, we will describe the configuration of Slack Notifications and Rules in Advanced Cluster Security

Slack Notification

Communication between Advanced Cluster Security and Slack is a built-in function. Besides the Slack integration, there are many other channels through which notifications can be sent. In 06_add-slack-notification.sh, curl is used to create a new notifier using Advanced Cluster Security’s API. In slack-post.json, you can see the body that is necessary for creating new notifiers in Advanced Cluster Security. The type “Slack” is used to define that this is a Slack channel and the labelDefault is used to store the route to the Slack webhook. 

A Slack app can be created at https://api.slack.com/apps/. As soon as you have activated incoming webhooks in the app, you are able to send corresponding messages to this Slack app via a URL, which then appear in the corresponding workspace. 

Deployment Rules

For this demo use case, a rule is set up that prevents the deployment of a UBI 7 image. In addition, it is configured that a violation of this rule leads to a deployment being canceled and a Slack notification being sent.

Installation of Deployment Pipeline

OpenShift Pipelines is used for the deployment pipeline. To do this, the operator is installed, a namespace is set up and a CI Pipeline API token is created in Advanced Cluster Security. This is then applied as a secret in the newly created namespace. The Kubernetes resources and scripts for this can be found in the pipeline-config folder of the Git repository. A pipeline resource itself, two pipeline tasks and the “pipeline runs” are responsible for the execution of the pipeline itself. The tasks are divided into a check task, which installs the roxctl CLI tool in the container and then validates the deployment using the API token, and a deployment task, which applies the deployment YAML in the cluster after a successful check. If you are interested in developing pipelines with Tekton, please have a look at the OpenShift documentation. 

Deployment execution and getting notifications

Once Advanced Cluster Security is configured and the pipeline has been successfully deployed in the cluster, we can start the corresponding failing or passing pipeline and apply the pipeline runs. In the failing pipeline, we will see that the pipeline terminates with an error and a message is sent to our Slack workspace. In the successful deployment, we will see that the pipeline turns green at the end the deployment is successfully completed.

Outlook

In the current state of the project, we see how we can use the Advanced Cluster Security and OpenShift Pipelines operators to prevent unwanted deployments from happening. The current implementation shows that we often have to rely on CURL commands and the use of the API when configuring Advanced Cluster Security. A next step for this project could be to migrate the shell scripts into Ansible playbooks to get a consistent level of automation. In addition, it is also conceivable to integrate further custom resources in the Advanced Cluster Security Operator, for example to manage notifiers or rules via YAML and thus also in a GitOps approach.