Security | Luis Cacho

Understanding the Compliance Operator

Tue, 16 Aug 2022 00:00:00 +0000

Table of Contents

Compliance studies a company’s security processes. It details their security at a moment in time and compares it to a specific set of regulatory requirements. These requirements come in the form of legislation, industry regulations, or standards created from best practices.

Every company can protect its data accordingly if they follow Compliance frameworks and have quality security in place. To have proper protection, companies must understand that Compliance is not the same thing as security. However, security is a big part of Compliance.

Becoming secure and compliant means securing information assets, preventing damage, protecting it, eliminating potential attack vectors and decreasing the system’s attack surface.

Compliance Operator Introduction

The Compliance Operator was released in OpenShift Container Platform v4.6, and allows OpenShift Container Platform administrators describe the desired compliance state of a cluster and provides them with an overview of gaps and ways to remediate them. The Compliance Operator assesses compliance of both the Kubernetes API resources of OpenShift Container Platform, as well as the nodes running the cluster. The Compliance Operator uses OpenSCAP, a NIST-certified tool, to scan and enforce security policies provided by the content.¹

The Compliance Operator is available for Red Hat Enterprise Linux CoreOS (RHCOS) deployments only.

To secure your OpenShift cluster, it is necessary to consider both; platform (Kubernetes/OpenShift API) and host OS (RHCOS) perspectives, because Kubernetes is composed of control plane machines (master) and worker machines (node), then the Kubernetes services such as API Server, etcd, or controller manager run on the control plane to manage the workloads on the worker machines.

Platform and Host Perspective

The basic approach to perform hardening in a RHCOS host is described in the documentation and it is based in the RHEL 8 Security Hardening. For instance, the hardening consists in validate if the file has appropriately restrictive file permissions, if the file ownership is appropriately set, if required systemd services or processes are launched with appropriate arguments or parameters in the configuration, or if the appropriate kernel parameters are set. Then, hardening the control plane is specific to the Kubernetes services and includes the control plane components or the master configuration files. It should validate if the API server has started with restrictive arguments regarding allowing specific admission plug-ins, enabling audit logging, applying etcd server and peer configurations, and restricting RBAC, among others. For clusters that use RHCOS, updating or upgrading are designed to become automatic events from the central control plane, because OpenShift completely controls the systems and services that run on each machine, including the operating system itself through the Machine Config Operator.

Why Compliance Operator?

Why is the Compliance Operator needed to validate the hardening and apply changes in the configuration of the operating system and the platform? The Compliance Operator is defined as follows:

The Compliance Operator lets OpenShift Container Platform administrators describe the required compliance state of a cluster and provides them with an overview of gaps and ways to remediate them. The Compliance Operator assesses compliance of both the Kubernetes API resources of OpenShift Container Platform, as well as the nodes running the cluster. The Compliance Operator uses OpenSCAP, a NIST-certified tool, to scan and enforce security policies provided by the content.¹

In other words, the Compliance Operator checks the host and the platform to detect gaps in compliance by specifying profiles for scan and creates summary reports about security compliance so that you will be able to find if there is any configuration that violates the policy in the cluster. The reports also show which remediations are applied, so you can choose if you want to apply the recommended configuration by hand, step-by-step, or automatically. In short, the whole process goes like this: choosing a profile for scanning, specifying the scan settings, then initiating the scan, and generating the reports.

Compliance Operator Overview

The Compliance Operator leverages OpenSCAP, a NIST-certified tool, to scan and enforce security policies, and the security policies for the compliance checks are derived through SCAP content and built from the community-based ComplianceAsCode/content project. A bundle of security policies, or profiles created by default when the operator is installed and profiles scheduled include NIST 800-53 Moderate (FedRAMP), Australian Cyber Security Centre (ACSC) Essential Eight, CIS OpenShift Benchmark, and others, so far. You can also create or tailor your own profiles so that you can pick the rules you want to run other than the profiles provided by default.

How can I implement Compliance Operator in my cluster?

First of all, you will need to install the Compliance Operator, for that, you can follow the documentation steps

Great, the Operator is installed and functional, now lets check how to create, run and evaluate a compliance scan.

References:

https://docs.openshift.com/container-platform/4.8/security/compliance_operator/compliance-operator-understanding.html ↩︎ ↩︎

Approve pending CSRs in OpenShift

Wed, 04 Aug 2021 00:00:00 +0000

for id in $(oc get csr | grep Pending | awk '{print $1}'); do oc adm certificate approve $id; done

Docker Login the Right Way

Wed, 15 May 2019 00:00:00 +0000

Table of Contents

Hi again!

It is been a while since I wrote something here, as always, there is no much time for a hobby.

I’ve been working for a while with docker, not a production level, but for some applications that I use at work. And since the Docker Hub Data breach I put more atention on the security of my data/credentials, so I investigate a little about and found this official repository https://github.com/docker/docker-credential-helpers/ from Docker where are the supported credential helpers.

Credential Store

Docker keeps our credentials saved on a JSON file located on ~/.docker/config.json, but unfortunatelly credentials are just encrypted on base64, here is an articule/video where there is an explanation for the why it is a bad idea to just use base64 encryption.

The following is a diagram on how a plain text storage works:

Plain Text Storage

Here is an example on how ~/.docker/config.json looks like when is using plain text credentials:

cat ~/.docker/config.json
{
 "auths": {
 "https://index.docker.io/v1/": {
 "auth": "azRjaDA6c3VwZXJzZWNyZXRwYXNzd29yZAo="
 },
 "quay.io": {
 "auth": "azRjaDA6c3VwZXJzZWNyZXRwYXNzd29yZAo="
 }
 },
 "HttpHeaders": {
 "User-Agent": "Docker-Client/18.09.6 (linux)"
 }
}

After a successful docker login command, Docker stores a base64 encoded string from the concatenation of the username, a colon, and the password and associates this string to the registry the user is logging into:

$ echo azRjaDA6c3VwZXJzZWNyZXRwYXNzd29yZAo= | base64 -d -
luiscachog:supersecretpassword

A docker logout command removes the entry from the JSON file for the given registry:

$ docker logout quay.io
Remove login credentials for quay.io

$ cat ~/.docker/config.json
{
 "auths": {
 "https://index.docker.io/v1/": {
 "auth": "azRjaDA6c3VwZXJzZWNyZXRwYXNzd29yZAo="
 }
 },
 "HttpHeaders": {
 "User-Agent": "Docker-Client/18.09.6 (linux)"
 }
}

Docker Credential Helpers

Since docker version 1.11 implements support from an external credential store for registry authentication. That means we can use a native keychain of the OS. Using an external store is more secure than storing on a “plain text” Docker configuration file.

Secure Storage

In order to use a external credential store, we need a program to interact with.

The actual list of “official” Docker Credential Helper is:

docker-credential-osxkeychain: Provides a helper to use the OS X keychain as credentials store.
docker-credential-secretservice: Provides a helper to use the D-Bus secret service as credentials store.
docker-credential-wincred: Provides a helper to use Windows credentials manager as store.
docker-credential-pass: Provides a helper to use pass as credentials store.

docker-credential-secret service

On this post we will explore the docker-credential-secretservice and how to configure it.

We need to download and install the helper. You can find the lastest release on https://github.com/docker/docker-credential-helpers/releases. Download it, extract it and make it executable.

wget https://github.com/docker/docker-credential-helpers/releases/download/v0.6.2/docker-credential-secretservice-v0.6.2-amd64.tar.gz
tar -xf docker-credential-secretservice-v0.6.2-amd64.tar.gz
chmod +x docker-credential-secretservice
sudo mv docker-credential-secretservice /usr/local/bin/

Then, we need to specify the credential store in the file ~/.docker/config.json to tell docker to use it. The value must be the one after the prefix docker-credential-. In this case:
```
{
 "credsStore": "secretservice"
}
```
To facilite the configuration and do not make mistakes, you can run:
```
sed -i '0,/{/s/{/{\n\t"credsStore": "secretservice",/' ~/.docker/config.json
```

From now we are uning an external store, so if you are currently logged in, you must run docker logout to remove the credentials from the file and run docker login tostart using the new ones.

Let me know how this works for you.