[Manual test] Review users, groups, serviceaccounts bound to cluster-admin: oc get clusterrolebindings | grep cluster-admin
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
[Manual test] Review Security Context Constraints: oc get scc
Use OpenShift’s Security Context Constraint feature, which has been contributed to Kubernetes as Pod Security Policies. PSPs are still beta in Kubernetes 1.10. OpenShift ships with two SCCs: restricted and privileged.
The two default SCCs will be created when the master is started. The restricted SCC is granted to all authenticated users by default.
https://docs.openshift.com/container-platform/3.10/admin_guide/manage_scc.html"
[Manual test] Review projects: oc get projects
[Manual test] Verify on masters the plugin being used: grep networkPluginName /etc/origin/master/master-config.yaml
OpenShift provides multi-tenant networking isolation (using Open vSwich and vXLAN), to segregate network traffic between containers belonging to different tenants (users or applications) while running on a shared cluster. Red Hat also works with 3rd-party SDN vendors to provide the same level of capabilities integrated with OpenShift. OpenShift SDN is included a part of OpenShift subscription.
OpenShift supports Kubernetes NetworkPolicy. Administrator must configure NetworkPolicies if desired.
Ansible Inventory variable: os_sdn_network_plugin_name: https://docs.openshift.com/container-platform/3.10/install/configuring_inventory_file.html
[Manual test] Verify SCCs that have been configured with seccomp: oc get scc -ocustom-columns=NAME:.metadata.name,SECCOMP-PROFILES:.seccompProfiles
OpenShift does not enable seccomp by default. To configure seccomp profiles that are applied to pods run by the SCC, follow the instructions in the documentation:
https://docs.openshift.com/container-platform/3.9/admin_guide/seccomp.html#admin-guide-seccomp
[Manual test] Review SCCs: oc describe scc
Use OpenShift’s Security Context Constraint feature, which has been contributed to Kubernetes as Pod Security Policies. PSPs are still beta in Kubernetes 1.10.
OpenShift ships with two SCCs: restricted and privileged. The two default SCCs will be created when the master is started. The restricted SCC is granted to all authenticated users by default.
All pods are run under the restricted SCC by default. Running a pod under any other SCC requires an account with cluster admin capabilities to grant access for the service account.
SecurityContextConstraints limit what securityContext is applied to pods and containers.
https://docs.openshift.com/container-platform/3.10/admin_guide/manage_scc.html
[Manual test] Review imagePolicyConfig in /etc/origin/master/master-config.yaml.
[Manual test] If ovs-networkplugin is used, review network policies: oc get networkpolicies
OpenShift supports Kubernetes NetworkPolicy via ovs-networkpolicy plugin. If choosing ovs-multitenant plugin, each namespace is isolated in its own netnamespace by default.
[Manual test]
Use OpenShift’s Security Context Constraint feature, which has been contributed to Kubernetes as Pod Security Policies. PSPs are still beta in Kubernetes 1.10.
OpenShift ships with two SCCs: restricted and privileged. The two default SCCs will be created when the master is started. The restricted SCC is granted to all authenticated users by default.
Similar scenarios are documented in the SCC documentation, which outlines granting SCC access to specific serviceaccounts. Administrators may create least-restrictive SCCs based on individual container needs.
For example, if a container only requires running as the root user, the anyuid SCC can be used, which will not expose additional access granted by running privileged containers.
https://docs.openshift.com/container-platform/3.10/admin_guide/manage_scc.html