apiVersion: v1
items:
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Restrict Automounting of Service Account Tokens
    Service accounts tokens should not be mounted in pods except where the workload running in the pod explicitly needs to communicate with the API server. To ensure pods do not automatically mount tokens, set automountServiceAccountToken to false.
  id: xccdf_org.ssgproject.content_rule_accounts_restrict_service_account_tokens
  instructions: |-
    For each pod in the cluster, review the pod specification and
    ensure that pods that do not need to explicitly communicate with
    the API server have automountServiceAccountToken
    configured to false.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: accounts-restrict-service-account-tokens
    creationTimestamp: "2024-11-28T02:41:39Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-accounts-restrict-service-account-tokens
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883265012"
    uid: 06450d6c-643e-4055-84d4-0c1a7d54163e
  rationale: Mounting service account tokens inside pods can provide an avenue for
    privilege escalation attacks where an attacker is able to compromise a single
    pod in the cluster.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: "Ensure Usage of Unique Service Accounts \nUsing the default service
    account prevents accurate application rights review and audit tracing. Instead
    of default , create a new and unique service account with the following command:\n\n$
    oc create sa service_account_name\n\nwhere service_account_name is the name of
    a service account that is needed in the project namespace."
  id: xccdf_org.ssgproject.content_rule_accounts_unique_service_account
  instructions: |-
    For each namespace in the cluster, review the rights assigned
    to the default service account. There should be no cluster or local roles
    assigned to the default other than the defaults.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: accounts-unique-service-account
    creationTimestamp: "2024-11-28T02:41:34Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-accounts-unique-service-account
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264758"
    uid: 6843ebfc-9843-46ae-9cc6-f7f068f4271d
  rationale: Kubernetes provides a default service account which is used by cluster
    workloads where no specific service account is assigned to the pod. Where access
    to the Kubernetes API from a pod is required, a specific service account should
    be created for that pod, and rights granted to that service account. This increases
    auditability of service account rights and access making it easier and more accurate
    to trace potential malicious behaviors to a specific service account and project.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Apply Security Context to Your Pods and Containers
    Apply Security Context to your Pods and Containers
  id: xccdf_org.ssgproject.content_rule_general_apply_scc
  instructions: |-
    Review the pod definitions in your cluster and verify they have appropriate
    security contexts. OpenShift comes configured with default security context
    constraints you can use immediately to secure pods in your cluster. For more
    information on security context constraints, how to use them, and how to
    build your own, please refer to the OpenShift security constraints documentation.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: general-apply-scc
    creationTimestamp: "2024-11-28T02:41:33Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-general-apply-scc
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264737"
    uid: dd46b33e-049f-4263-b23a-77813d278634
  rationale: 'A security context defines the operating system security settings (uid,
    gid, capabilities, SELinux role, etc..) applied to a container. When designing
    your containers and pods, make sure that you configure the security context for
    your pods, containers, and volumes. A security context is a property defined in
    the deployment yaml. It controls the security parameters that will be assigned
    to the pod/container/volume. There are two levels of security context: pod level
    security context, and container level security context.'
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    The default namespace should not be used
    Kubernetes provides a default namespace, where objects are placed if no namespace is specified for them. Placing objects in this namespace makes application of RBAC and other controls more difficult.
  id: xccdf_org.ssgproject.content_rule_general_default_namespace_use
  instructions: |-
    Run the following command to list objects in the default namespace:
    $ oc get all -n default
    The only entries there should be system-managed resources such as the
    kubernetes and openshift service.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: general-default-namespace-use
    creationTimestamp: "2024-11-28T02:41:38Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-general-default-namespace-use
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264925"
    uid: 9e8755cd-d0cd-480e-a52f-e7e62a98e4c7
  rationale: Resources in a Kubernetes cluster should be segregated by namespace,
    to allow for security controls to be applied at that level and to make it easier
    to manage resources.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Ensure Seccomp Profile Pod Definitions
    Enable default seccomp profiles in your pod definitions.
  id: xccdf_org.ssgproject.content_rule_general_default_seccomp_profile
  instructions: |-
    In OpenShift 4, CRI-O is the supported runtime. CRI-O runs unconfined by
    default in order to meet CRI conformance criteria.  On RHEL CoreOS, the
    default seccomp policy is associated with CRI-O and stored in
    /etc/crio/seccomp.json.  The default profile is applied when the user asks
    for the runtime/default profile via annotation to the pod and when the
    associated SCC allows use of the specified seccomp profile.

    Configuration of allowable seccomp profiles is managed through OpenShift
    Security Context Constraints.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: general-default-seccomp-profile
    creationTimestamp: "2024-11-28T02:41:37Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-general-default-seccomp-profile
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264892"
    uid: bd055a8c-83e2-4f64-ba0d-442b52ef8364
  rationale: Seccomp (secure computing mode) is used to restrict the set of system
    calls applications can make, allowing cluster administrators greater control over
    the security of workloads running in the cluster. Kubernetes disables seccomp
    profiles by default for historical reasons. You should enable it to ensure that
    the workloads have restricted actions available within the container.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Create administrative boundaries between resources using namespaces
    Use namespaces to isolate your Kubernetes objects.
  id: xccdf_org.ssgproject.content_rule_general_namespaces_in_use
  instructions: |-
    OpenShift projects wrap Kubernetes namespaces and are used by default in
    OpenShift 4.  Run the following command and review the namespaces created in
    the cluster.  $ oc get namespaces Ensure that the namespaces are
    the ones you need and are adequately administered.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: general-namespaces-in-use
    creationTimestamp: "2024-11-28T02:41:40Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-general-namespaces-in-use
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883265079"
    uid: 0fbf59ae-16e6-48d6-aae4-4bf7912fefb5
  rationale: Limiting the scope of user permissions can reduce the impact of mistakes
    or malicious activities. A Kubernetes namespace allows you to partition created
    resources into logically named groups. Resources created in one namespace can
    be hidden from other namespaces. By default, each resource created by a user in
    Kubernetes cluster runs in a default namespace, called default. You can create
    additional namespaces and attach resources and users to them. You can use Kubernetes
    Authorization plugins to create policies that segregate access to namespace resources
    between different users.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Ensure that the RBAC setup follows the principle of least privilege
    Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. If users or groups exist that are bound to roles they must not have, modify the user or group permissions using the following cluster and local role binding commands: Remove a User from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-user role username Remove a Group from a Cluster RBAC role by executing the following: oc adm policy remove-cluster-role-from-group role groupname Remove a User from a Local RBAC role by executing the following: oc adm policy remove-role-from-user role username Remove a Group from a Local RBAC role by executing the following: oc adm policy remove-role-from-group role groupname NOTE: For additional information. https://docs.openshift.com/container-platform/latest/authentication/using-rbac.html
  id: xccdf_org.ssgproject.content_rule_rbac_least_privilege
  instructions: |-
    The administrator must verify that Openshift is configured with the necessary RBAC access controls.

    Review the RBAC configuration.

    As the cluster-admin, view the cluster roles and their associated rule sets by executing the following::

    oc describe clusterrole.rbac

    Now view the current set of cluster role bindings, which shows the users and groups that are bound to various roles by executing the following:

    oc describe clusterrolebinding.rbac

    Local roles and bindings can be determined using the follow commands by executing the following:

    oc describe rolebinding.rbac

    If these results show users with privileged access that do not require that access, this is a finding.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: rbac-least-privilege
    creationTimestamp: "2024-11-28T02:41:39Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: high
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-rbac-least-privilege
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883265006"
    uid: 6d61bf0c-3d0a-4b61-bb9f-2a90470f47bc
  rationale: Controlling and limiting users access to system services and resources
    is key to securing the platform and limiting the intentional or unintentional
    comprimising of the system and its services. OpenShift provides a robust RBAC
    policy system that allows for authorization policies to be as detailed as needed.
    Additionally there are two layers of RBAC policies, the first is Cluster RBAC
    policies which administrators can control who has what access to cluster level
    services. The other is Local RBAC policies, which allow project developers/administrators
    to control what level of access users have to a given project or namespace.
  severity: high
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Ensure that the cluster-admin role is only used where required
    The RBAC role cluster-admin provides wide-ranging powers over the environment and should be used only where and when needed.
  id: xccdf_org.ssgproject.content_rule_rbac_limit_cluster_admin
  instructions: |-
    Review users and groups bound to cluster-admin and decide whether they
    require such access. Consider creating least-privilege roles for users and
    service accounts. Obtain a list of the users who have access to the
    cluster-admin role by reviewing the clusterrolebinding output for each role
    binding that has access to the cluster-admin role. To do this, run the
    following command:
    $ oc get clusterrolebindings -o=custom-columns=NAME:.metadata.name,ROLE:.roleRef.name,SUBJECT:.subjects[*].kind | grep cluster-admin

    Care should be taken before removing any clusterrolebindings from the
    environment to ensure they are not required for operation of the cluster.
    Specifically, modifications should not be made to the default
    clusterrolebindings including those with the "system:" prefix.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: rbac-limit-cluster-admin
    creationTimestamp: "2024-11-28T02:41:36Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-rbac-limit-cluster-admin
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264859"
    uid: 3de396c3-3b48-478a-a53a-aa9c11f9ad64
  rationale: Kubernetes provides a set of default roles where RBAC is used. Some of
    these roles such as cluster-admin provide wide-ranging privileges which should
    only be applied where absolutely necessary. Roles such as cluster-admin allow
    super-user access to perform any action on any resource. When used in a ClusterRoleBinding,
    it gives full control over every resource in the cluster and in all namespaces.
    When used in a RoleBinding, it gives full control over every resource in the rolebinding's
    namespace, including the namespace itself.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Limit Access to Kubernetes Secrets
    The Kubernetes API stores secrets, which may be service account tokens for the Kubernetes API or credentials used by workloads in the cluster. Access to these secrets should be restricted to the smallest possible group of users to reduce the risk of privilege escalation. To restrict users from secrets, remove get , list , and watch access to unauthorized users to secret objects in the cluster.
  id: xccdf_org.ssgproject.content_rule_rbac_limit_secrets_access
  instructions: |-
    To review the policy rules assigned to roles in all namespaces, run
    the following command:
    $ for ns in $(oc get projects -ojsonpath='{.items[*].metadata.name}'); do oc describe roles -n$ns; done
    To review the policy rules assigned to cluster roles, run the following
    command:
    $ for i in $(oc get clusterroles -o jsonpath='{.items[*].metadata.name}'); do oc describe clusterrole ${i}; done
    Review the output and ensure that only authorized roles have access to the
    secrets resource or all resources using a wildcard.
    To filter clusterroles that have assigned access to the secrets resources for clustrroles, run:
    $ oc get clusterroles -ojson | jq -r '.items[] | {name: .metadata.name, rules: .rules} | select(.rules[]?.resources | try contains(["secrets"])) | .name' | sort | uniq
    and similarly to filter namespace/role pairs:
    $ for ns in $(oc get projects -ojsonpath='{.items[*].metadata.name}'); do oc get roles -n$ns -ojson | jq -r '.items[] | {name: .metadata.name, namespace: .metadata.namespace, rules: .rules} | select(.rules[]?.resources | try contains(["secrets"])) | "\(.namespace)/\(.name)"' | sort | uniq; done
    note that the two commands above do not show roles and/or clusterroles with wildcard access to any resources.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: rbac-limit-secrets-access
    creationTimestamp: "2024-11-28T02:41:37Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-rbac-limit-secrets-access
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264875"
    uid: 3c5bbd32-18c6-4068-bb57-b856b6b07184
  rationale: Inappropriate access to secrets stored within the Kubernetes cluster
    can allow for an attacker to gain additional access to the Kubernetes cluster
    or external resources whose credentials are stored as secrets.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Minimize Access to Pod Creation
    The ability to create pods in a namespace can provide a number of opportunities for privilege escalation. Where applicable, remove create access to pod objects in the cluster.
  id: xccdf_org.ssgproject.content_rule_rbac_pod_creation_access
  instructions: |-
    To review the pod creation privileges in roles, run the following commands:
    $ oc describe roles --all-namespaces
    $ oc describe clusterroles
    Review the output, and for any role/clusterrole defining create permissions
    for pods that are NOT an OpenShift "system:" or other system-provided
    role/clusterrole, determine if the users bound to the role truly have the
    need to create pods.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: rbac-pod-creation-access
    creationTimestamp: "2024-11-28T02:41:33Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-rbac-pod-creation-access
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264717"
    uid: d5ce9f98-6ebf-4671-b128-c633f89cef06
  rationale: The ability to create pods in a cluster opens up the cluster for privilege
    escalation.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Minimize Wildcard Usage in Cluster and Local Roles
    Kubernetes Cluster and Local Roles provide access to resources based on sets of objects and actions that can be taken on those objects. It is possible to set either of these using a wildcard * which matches all items. This violates the principle of least privilege and leaves a cluster in a more vulnerable state to privilege abuse.
  id: xccdf_org.ssgproject.content_rule_rbac_wildcard_use
  instructions: |-
    To review the wildcard usage in roles, run the following commands:
    $ oc describe roles --all-namespaces
    $ oc describe clusterroles
    Review the output, and for any role/clusterrole specifying a wildcard
    resource that is NOT an OpenShift "system:" or other system-provided
    role/clusterrole, determine if the wildcard access can be replaced with
    specific resources.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: rbac-wildcard-use
    creationTimestamp: "2024-11-28T02:41:41Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-rbac-wildcard-use
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883265083"
    uid: 91d90799-649e-45ef-94b9-f41da0e10628
  rationale: The principle of least privilege recommends that users are provided only
    the access required for their role and nothing more. The use of wildcard rights
    grants is likely to provide excessive rights to the Kubernetes API.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Drop Container Capabilities
    Containers should not enable more capabilities than needed as this opens the door for malicious use. To disable the capabilities, the appropriate Security Context Constraints (SCCs) should set all capabilities as * or a list of capabilities in requiredDropCapabilities.
  id: xccdf_org.ssgproject.content_rule_scc_drop_container_capabilities
  instructions: |-
    Inspect each SCC returned from running the following command:
    $ oc get scc
    Next, examine the outputs of the following commands:
    $ oc describe roles --all-namespaces
    $ oc describe clusterroles
    For any role/clusterrole that reference the
    securitycontextconstraints resource with the resourceNames
    of the SCCs that do not list any requiredDropCapabilities, examine the
    associated rolebindings to account for the users that are bound to the role.
    Review each SCC and determine that all capabilities are either
    completely disabled as a list entry under requiredDropCapabilities,
    or that all the un-required capabilities are dropped for containers and SCCs.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: scc-drop-container-capabilities
    creationTimestamp: "2024-11-28T02:41:33Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-scc-drop-container-capabilities
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264730"
    uid: 3af6913d-45e5-44f8-a18b-a4d204ed7bf9
  rationale: By default, containers run with a default set of capabilities as assigned
    by the Container Runtime which can include dangerous or highly privileged capabilities.
    Capabilities should be dropped unless absolutely critical for the container to
    run software as added capabilities that are not required allow for malicious containers
    or attackers.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Limit Access to the Host IPC Namespace
    Containers should not be allowed access to the host's Interprocess Communication (IPC) namespace. To prevent containers from getting access to a host's IPC namespace, the appropriate Security Context Constraints (SCCs) should set allowHostIPC to false.
  id: xccdf_org.ssgproject.content_rule_scc_limit_ipc_namespace
  instructions: |-
    Inspect each SCC returned from running the following command:
    $ oc get scc
    Review each SCC for those that have allowHostIPC set to true.
    Next, examine the outputs of the following commands:
    $ oc describe roles --all-namespaces
    $ oc describe clusterroles
    For any role/clusterrole that reference the
    securitycontextconstraints resource with the resourceNames
    of the SCCs that have allowHostIPC, examine the associated
    rolebindings to account for the users that are bound to the role. Review the
    account to determine if allowHostIPC is truly required.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: scc-limit-ipc-namespace
    creationTimestamp: "2024-11-28T02:41:37Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-scc-limit-ipc-namespace
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264900"
    uid: 0e4d6e01-0d6b-4860-b464-83334e8b9ece
  rationale: A container running in the host's IPC namespace can use IPC to interact
    with processes outside the container potentially allowing an attacker to exploit
    a host process thereby enabling an attacker to exploit other services.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Limit Use of the CAP_NET_RAW
    Containers should not enable more capabilities than needed as this opens the door for malicious use. CAP_NET_RAW enables a container to launch a network attack on another container or cluster. To disable the CAP_NET_RAW capability, the appropriate Security Context Constraints (SCCs) should set NET_RAW in requiredDropCapabilities.
  id: xccdf_org.ssgproject.content_rule_scc_limit_net_raw_capability
  instructions: |-
    Inspect each SCC returned from running the following command:
    $ oc get scc
    Review each SCC for those that do not have NET_RAW or ALL set under requiredDropCapabilities.
    Next, examine the outputs of the following commands:
    $ oc describe roles --all-namespaces
    $ oc describe clusterroles
    For any role/clusterrole that reference the
    securitycontextconstraints resource with the resourceNames
    of the SCCs that do not drop NET_RAW or ALL, examine the
    associated rolebindings to account for the users that are bound to the role.
    Review each SCC and determine that either NET_RAW or ALL
    is either included as a list entry under requiredDropCapabilities,
    or that either NET_RAW or ALL is only enabled to a small
    set of containers and SCCs.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: scc-limit-net-raw-capability
    creationTimestamp: "2024-11-28T02:41:34Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-scc-limit-net-raw-capability
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264785"
    uid: 7f251522-1177-4d79-bd4a-eada248662f4
  rationale: By default, containers run with a default set of capabilities as assigned
    by the Container Runtime which can include dangerous or highly privileged capabilities.
    If the CAP_NET_RAW is enabled, it may be misused by malicious containers or attackers.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Limit Access to the Host Network Namespace
    Containers should not be allowed access to the host's network namespace. To prevent containers from getting access to a host's network namespace, the appropriate Security Context Constraints (SCCs) should set allowHostNetwork to false.
  id: xccdf_org.ssgproject.content_rule_scc_limit_network_namespace
  instructions: |-
    Inspect each SCC returned from running the following command:
    $ oc get scc
    Review each SCC for those that have allowHostNetwork set to true.
    Next, examine the outputs of the following commands:
    $ oc describe roles --all-namespaces
    $ oc describe clusterroles
    For any role/clusterrole that reference the
    securitycontextconstraints resource with the resourceNames
    of the SCCs that have allowHostNetwork, examine the associated
    rolebindings to account for the users that are bound to the role. Review the
    account to determine if allowHostNetwork is truly required.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: scc-limit-network-namespace
    creationTimestamp: "2024-11-28T02:41:34Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-scc-limit-network-namespace
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264771"
    uid: be6441e9-5835-4d09-a3c6-88df29c29282
  rationale: A container running in the host's network namespace could access the
    host network traffic to and from other pods potentially allowing an attacker to
    exploit pods and network traffic.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Limit Containers Ability to Escalate Privileges
    Containers should be limited to only the privileges required to run and should not be allowed to escalate their privileges. To prevent containers from escalating privileges, the appropriate Security Context Constraints (SCCs) should set allowPrivilegeEscalation to false.
  id: xccdf_org.ssgproject.content_rule_scc_limit_privilege_escalation
  instructions: |-
    Inspect each SCC returned from running the following command:
    $ oc get scc
    Review each SCC for those that have allowPrivilegeEscalation set to true.
    Next, examine the outputs of the following commands:
    $ oc describe roles --all-namespaces
    $ oc describe clusterroles
    For any role/clusterrole that reference the
    securitycontextconstraints resource with the resourceNames
    of the SCCs that have allowPrivilegeEscalation, examine the associated
    rolebindings to account for the users that are bound to the role. Review the
    account to determine if allowPrivilegeEscalation is truly required.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: scc-limit-privilege-escalation
    creationTimestamp: "2024-11-28T02:41:38Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-scc-limit-privilege-escalation
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264937"
    uid: 14e2be80-7b6a-49c4-a423-805fbe6564b7
  rationale: Privileged containers have access to more of the Linux Kernel capabilities
    and devices. If a privileged container were compromised, an attacker would have
    full access to the container and host.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Limit Privileged Container Use
    Containers should be limited to only the privileges required to run. To prevent containers from running as privileged containers, the appropriate Security Context Constraints (SCCs) should set allowPrivilegedContainer to false.
  id: xccdf_org.ssgproject.content_rule_scc_limit_privileged_containers
  instructions: |-
    Inspect each SCC and the users and groups allowed to use it returned
    from running the following command:
    oc get scc -ojson | jq '.items[]|select(.allowPrivilegedContainer)|.metadata.name,{"Group:":.groups},{"User":.users}'

    The group "system:authenticated" is the default group for any
    authenticated user, this group should only be associated with the
    restricted profile. If this group is listed under any other SCC Policy,
    or the restricted SCC policy has been altered to allow any of the
    non-permitted actions, this is a finding.

    Next, determine if there are any cluster roles or local roles that allow
    the use of use of non-permitted SCC policies.  The following commands will
    print the Role's name and namespace, followed by a list of resource names
    and if that resource is an SCC.

    > oc get clusterrole.rbac -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}'

    > oc get role.rbac --all-namespaces -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}'

    Excluding platform specific roles, identify any roles that allow use of non-permitted SCC policies for example the follow output shows that the role 'examplePrivilegedRole' allows use of the 'privileged' SCC.


    examplePrivilegedRole
    {
      "scc": "privileged"
    }


    Finally, determine if there are any role bindings to cluster or local
    roles that allow use of non-permitted SCCs.

    > oc get clusterrolebinding.rbac -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ("[CLUSTER_ROLE_LIST]"))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}'
    > oc get rolebinding.rbac --all-namespaces -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ("[LOCAL_ROLE_LIST]"))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}'

    Where "[CLUSTER_ROLE_LIST]" and "[LOCAL_ROLE_LIST]" are
    comma-separated lists of the roles allowing use of non-permitted SCC
    policies as identified above. For example:


    ... .roleRef.name == ("system:openshift:scc:privileged","system:openshift:scc:hostnetwork","system:openshift:scc:hostaccess") ...


    Excluding any platform namespaces (kube-*,openshift-*), if there are any rolebindings to roles that are not permitted, this is a finding.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: scc-limit-privileged-containers
    creationTimestamp: "2024-11-28T02:41:33Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-scc-limit-privileged-containers
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264731"
    uid: fc642e17-2f0c-483f-bab6-2f525e40a1eb
  rationale: Privileged containers have access to all Linux Kernel capabilities and
    devices. If a privileged container were compromised, an attacker would have full
    access to the container and host.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Limit Access to the Host Process ID Namespace
    Containers should not be allowed access to the host's process ID namespace. To prevent containers from getting access to a host's process ID namespace, the appropriate Security Context Constraints (SCCs) should set allowHostPID to false.
  id: xccdf_org.ssgproject.content_rule_scc_limit_process_id_namespace
  instructions: |-
    Inspect each SCC returned from running the following command:
    $ oc get scc
    Review each SCC for those that have allowHostPID set to true.
    Next, examine the outputs of the following commands:
    $ oc describe roles --all-namespaces
    $ oc describe clusterroles
    For any role/clusterrole that reference the
    securitycontextconstraints resource with the resourceNames
    of the SCCs that have allowHostPID, examine the associated
    rolebindings to account for the users that are bound to the role. Review the
    account to determine if allowHostPID is truly required.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: scc-limit-process-id-namespace
    creationTimestamp: "2024-11-28T02:41:35Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-scc-limit-process-id-namespace
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264807"
    uid: bdd109df-8126-4d63-8c60-c91accfb4b66
  rationale: A container running in the host's PID namespace can inspect processes
    running outside the container which can be used to escalate privileges outside
    of the container.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Limit Container Running As Root User
    Containers should run as a random non-privileged user. To prevent containers from running as root user, the appropriate Security Context Constraints (SCCs) should set.runAsUser.type to MustRunAsRange.
  id: xccdf_org.ssgproject.content_rule_scc_limit_root_containers
  instructions: |-
    Inspect each SCC and the users and groups allowed to use it returned
    from running the following command:
    oc get scc -ojson | jq '.items[]|select(.runAsUser.type != "MustRunAsRange" )|.metadata.name,{"Group:":.groups},{"User":.users}'

    The group "system:authenticated" is the default group for any
    authenticated user, this group should only be associated with the
    restricted profile. If this group is listed under any other SCC Policy,
    or the restricted SCC policy has been altered to allow any of the
    non-permitted actions, this is a finding.

    Next, determine if there are any cluster roles or local roles that allow
    the use of use of non-permitted SCC policies.  The following commands will
    print the Role's name and namespace, followed by a list of resource names
    and if that resource is an SCC.

    > oc get clusterrole.rbac -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}'

    > oc get role.rbac --all-namespaces -ojson | jq -r '.items[]|select(.rules[]?|select( (.apiGroups[]? == ("security.openshift.io")) and (.resources[]? == ("securitycontextconstraints")) and (.verbs[]? == ("use"))))|.metadata.name,{"scc":(.rules[]?|select((.resources[]? == ("securitycontextconstraints"))).resourceNames[]?)}'

    Excluding platform specific roles, identify any roles that allow use of non-permitted SCC policies for example the follow output shows that the role 'examplePrivilegedRole' allows use of the 'privileged' SCC.


    examplePrivilegedRole
    {
      "scc": "privileged"
    }


    Finally, determine if there are any role bindings to cluster or local
    roles that allow use of non-permitted SCCs.

    > oc get clusterrolebinding.rbac -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ("[CLUSTER_ROLE_LIST]"))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}'
    > oc get rolebinding.rbac --all-namespaces -ojson | jq -r '.items[]|select(.roleRef.kind == ("ClusterRole","Role") and .roleRef.name == ("[LOCAL_ROLE_LIST]"))|{ "crb": .metadata.name, "roleRef": .roleRef, "subjects": .subjects}'

    Where "[CLUSTER_ROLE_LIST]" and "[LOCAL_ROLE_LIST]" are
    comma-separated lists of the roles allowing use of non-permitted SCC
    policies as identified above. For example:


    ... .roleRef.name == ("system:openshift:scc:privileged","system:openshift:scc:hostnetwork","system:openshift:scc:hostaccess") ...


    Excluding any platform namespaces (kube-*,openshift-*), if there are any rolebindings to roles that are not permitted, this is a finding.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: scc-limit-root-containers
    creationTimestamp: "2024-11-28T02:41:37Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-scc-limit-root-containers
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264902"
    uid: 1ece6de7-2876-40eb-a9b2-983de2fb4c45
  rationale: It is strongly recommended that containers running on OpenShift should
    support running as any arbitrary UID. OpenShift will then assign a random, non-privileged
    UID to the running container instance. This avoids the risk from containers running
    with specific uids that could map to host service accounts, or an even greater
    risk of running as root level service. OpenShift uses the default security context
    constraints (SCC), restricted, to prevent containers from running as root or other
    privileged user ids. Pods may be configured to use an scc policy that allows the
    container to run as a specific uid, including root(0) when approved. Only a cluster
    administrator may grant the change of an scc policy.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Consider external secret storage
    Consider the use of an external secrets storage and management system, instead of using Kubernetes Secrets directly, if you have more complex secret management needs. Ensure the solution requires authentication to access secrets, has auditing of access to and use of secrets, and encrypts secrets. Some solutions also make it easier to rotate secrets.
  id: xccdf_org.ssgproject.content_rule_secrets_consider_external_storage
  instructions: |-
    Review the cluster configuration and determine if an appropriate secrets
    manager has been configured.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: secrets-consider-external-storage
    creationTimestamp: "2024-11-28T02:41:39Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-secrets-consider-external-storage
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883265008"
    uid: 16eed437-96ae-4dec-9a30-bf4875a95942
  rationale: Kubernetes supports secrets as first-class objects, but care needs to
    be taken to ensure that access to secrets is carefully limited. Using an external
    secrets provider can ease the management of access to secrets, especially where
    secrets are used across both Kubernetes and non-Kubernetes environments.
  severity: medium
  status: MANUAL
- apiVersion: compliance.openshift.io/v1alpha1
  description: |-
    Do Not Use Environment Variables with Secrets
    Secrets should be mounted as data volumes instead of environment variables.
  id: xccdf_org.ssgproject.content_rule_secrets_no_environment_variables
  instructions: |-
    To find workloads that use environment variables for secrets, run the following:
    $ oc get all -o jsonpath='{range .items[?(@..secretKeyRef)]} {.kind} {.metadata.namespace} {.metadata.name} {"\n"}{end}' -A
    Review the output and ensure that workloads that can mount secrets as data
    volumes use that instead of environment variables.
  kind: ComplianceCheckResult
  metadata:
    annotations:
      compliance.openshift.io/rule: secrets-no-environment-variables
    creationTimestamp: "2024-11-28T02:41:35Z"
    generation: 1
    labels:
      compliance.openshift.io/check-severity: medium
      compliance.openshift.io/check-status: MANUAL
      compliance.openshift.io/scan-name: ocp4-cis
      compliance.openshift.io/suite: compliance-cis
    name: ocp4-cis-secrets-no-environment-variables
    namespace: openshift-compliance
    ownerReferences:
    - apiVersion: compliance.openshift.io/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: ComplianceScan
      name: ocp4-cis
      uid: 4947a377-3431-4e6c-974f-d22fb97261fb
    resourceVersion: "883264829"
    uid: 0a9bb0d3-4c29-4c91-afbf-dd16cf6f4402
  rationale: Environment variables are subject and very susceptible to malicious hijacking
    methods by an adversary, as such, environment variables should never be used for
    secrets.
  severity: medium
  status: MANUAL
kind: List
metadata:
  resourceVersion: ""
