Red Hat disagrees with the CIS recommendation for the protect-kernel-defauts. OpenShift node/kubelet modifies the system tunable; using the protect-kernel-defaults flag will cause the kubelet to fail on start if the tunables don't match what the kubelet desires and the OpenShift node to fail to start. For more information, see https://bugzilla.redhat.com/show_bug.cgi?id=1434318 (closed Won't Fix).
The expected tunable values are listed here:
https://github.com/openshift/origin/blob/release-3.10/vendor/k8s.io/kubernetes/pkg/util/sysctl/sysctl.go#L28-L42

Unauthenticated/Unauthorized users have no access to OpenShift nodes.  The kubelet flag authorization-mode is explicitly set to WebHook

Since Webhook is the default value, the authorization-mode configuration is not needed in node-config.  If it is configured, ensure the value is only set to ‘Webhook’.  The node systemd service (atomic-openshift-node) will not start if the configuration value is set to anything other than Webhook.

Red Hat disagrees with the CIS recommendation to disable anonymous-auth and OpenShift uses a different approach to secure anonymous authorization. OpenShift explicitly sets anonymous-auth to true, as anonymous requests are used for discovery information, webhook integrations, etc. OpenShift allows anonymous requests (then authorizes them).
Access to OpenShift node is authenticated with certificate.  kubelet apis are subresources of the node resource that can be restricted by RBAC roles.  Anonymous access is denied for these subresources. OpenShift provides it's own fully integrated authentication and authorization mechanism. Unsecured endpoints reveal no sensitive data. Unauthenticated requests to secured endpoints are assigned to 'system:anonymous'. system:anonymous is not bound to any roles, and thus has no visibility by default. See https://docs.openshift.com/container-platform/3.10/install_config/configuring_authentication.html

OpenShift uses Security Context Constraints to prevent privileged containers from running by default. OpenShift explicitly sets the allow-privileged kubelet flag, but does not allow privileged container by default. To create privileged pod, the user/serviceAccount must be granted access to the privileged SCC; only cluster-admin can grant SCC privileges.  Some platform-level components (e.g. fluentd, sdn, ovs which run on every node) must run as privileged, thus disabling the flag would affect platform features. Review users and groups who may create privileged containers as described in 6.9.

default is false, and false is the pass condition.
updated OVAL to fail only when true is present.

default value is false. update OVAL to fail upon "true"

…sato/scap-security-guide into yuumasato-update_contributors_0_1_43

…p-security-guide into redhatrises-rhv_ospp_profile

* 'rhv_ospp_profile' of https://github.com/redhatrises/scap-security-guide:
  Add draft RHVH FISMA Low profile

Misc updates to OCP content

- Ansible versions < 2.5 are no longer supported

- With Crypto policies now shipped in RHEL8/Fedora, the SSH rules that checked
  that ciphers and macs where configured for FIPS are now out-of-date and deprecated.
  They should no longer be built with RHEL8/Fedora content. The rules have been now
  replaced by the configure_ssh_crypto_policy rule.

Remove out-of-date crypto rules from RHEL8/Fedora builds

RHVH FISMA Low profile

Bump supported ansible version to 2.5

- Part of #3794

Map lkinser to Lee Kinser in ssg/contributors.py