cis-ocp-v160-3-1-1

name	cis-ocp-v160-3.1.1
description	Client certificate authentication should not be used for users (Manual)
category	cis-openshift
version	1.6.0
author	cyberstrike-official
tags	["cis","openshift","kubernetes","redhat","authentication","authorization","client-certificate","identity-provider","oauth"]
cis_id	3.1.1
cis_benchmark	CIS Red Hat OpenShift Container Platform Benchmark v1.6.0
tech_stack	["kubernetes","openshift","redhat"]
cwe_ids	[]
chains_with	[]
prerequisites	[]
severity_boost	{}

CIS Red Hat OpenShift Container Platform Benchmark v1.6.0 - Control 3.1.1

Profile Applicability

• Level: 2

Description

Kubernetes provides the option to use client certificates for user authentication. However as there is no way to revoke these certificates when a user leaves an organization or loses their credential, they are not suitable for this purpose.

It is not possible to fully disable client certificate use within a cluster as it is used for component to component authentication.

Rationale

With any authentication mechanism the ability to revoke credentials if they are compromised or no longer required, is a key control. Kubernetes client certificate authentication does not allow for this due to a lack of support for certificate revocation.

Impact

External mechanisms for authentication generally require additional software to be deployed.

Audit Procedure

For users to interact with OpenShift Container Platform, they must first authenticate to the cluster. The authentication layer identifies the user with requests to the OpenShift Container Platform API. The authorization layer then uses information about the requesting user to determine if the request is allowed.

The OpenShift Container Platform includes a built-in OAuth server for token-based authentication. Developers and administrators obtain OAuth access tokens to authenticate themselves to the API. It is recommended for an administrator to configure OAuth to specify an identity provider after the cluster is installed. User access to the cluster is managed through the identity provider.

First, verify user authentication is enabled:

oc describe authentication

Next, verify an identity provider is configured:

oc get oauth -o json  | jq '.items[].spec.identityProviders'

Verify at least one identity provider is configured, and verify that the kubeadmin user does not exist.

Next, verify a cluster-admin user exists:

oc get clusterrolebindings -o='custom-columns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECT:.subjects[*].kind' | grep cluster-admin | grep User

Verify at least one user has the cluster-admin role.

Finally, verify that the kubeadmin secret is removed:

oc get secrets kubeadmin -n kube-system

No result is expected.

Remediation