UCF STIG Viewer Logo
Changes are coming to https://stigviewer.com. Take our survey to help us understand your usage and how we can better serve you in the future.
Take Survey

Vulnerability scanning applications must implement privileged access authorization to all OpenShift components, containers, and container images for selected organization-defined vulnerability scanning activities.


Overview

Finding ID Version Rule ID IA Controls Severity
V-257563 CNTR-OS-000770 SV-257563r921632_rule Medium
Description
OpenShift uses service accounts to provide applications running on or off the platform access to the API service using the enforced RBAC policies. Vulnerability scanning applications that need access to the container platform may use a service account to grant that access. That service account can then be bound to the appropriate role required. The highest level of access granted is the cluster-admin role. Any account bound to that role can access and modify anything on the platform. It is strongly recommended to limit the number of accounts bound to that role. Instead, there are other predefined cluster level roles that may support the scanning to, such as the view or edit cluster roles. Additionally, custom roles may be defined to tailor fit access as needed by the scanning tools.
STIG Date
Red Hat OpenShift Container Platform 4.12 Security Technical Implementation Guide 2023-08-28

Details

Check Text ( C-61298r921630_chk )
If no vulnerability scanning tool is used, this requirement is Not Applicable.

Identify the service accounts used by the vulnerability scanning tools. If the tool runs as a container on the platform, then service account information can be found in the pod details by executing the following:

(oc get pods to list pods)
oc get pod -o jsonpath='{.spec.serviceAccount}{"\n"}'

If no service account exists for the vulnerability scanning tool, this is a finding.

View cluster role bindings to determine which role the service account is bound to by executing the following:

oc get clusterrolebinding -ojson | jq '.items[]|select(.subjects[]?|select(.kind == "ServiceAccount" and .name == "ingress-to-route-controller"))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}'

Find the role to which the service account is bound, if the service account is not bound to a cluster role, or the role does not provide sufficient access, this is a finding.
Fix Text (F-61222r921631_fix)
If no vulnerability scanning tool is used, this requirement is Not Applicable.

Create a service if one does not already exist.

Change to the appropriate namespace by executing the following:

oc project

Create Service Account in the Project by executing the following:

oc create sa

Verify creation of the Service Account by executing the following:

oc get sa | grep

Bind to the appropriate cluster RBAC role by executing the following:

oc adm policy add-cluster-role-to-user -z

For more information, refer to the following guides:
https://docs.openshift.com/container-platform/4.8/authentication/using-rbac.html

https://docs.openshift.com/container-platform/4.8/authentication/understanding-and-creating-service-accounts.html

https://docs.openshift.com/container-platform/4.8/authentication/using-service-accounts-in-applications.html