Let me take a stab at this, as a Red Hat architect that spends a lot of time on OpenShift(OCP) implementations: OpenShift helps mitigate the following, by prov

Let me take a stab at this, as a Red Hat architect that spends a lot of time on OpenShift(OCP) implementations: OpenShift helps mitigate the following, by providing secure defaults. It is totally possible for someone (a cluster level admin) to un-configure these security controls, so keep that in mind. These are partially mitigated by Red Hat providing trusted image content and having a well oiled machine for patching/CVE response: * Compromised images in registry (use Red Hat base images, and in-cluster source or docker builds to lock down registry access. Registry not exposed by default.) * Application vulnerability/Application exploit (again, Red Hat base images for runtime, regularly patched by Red Hat. Images have to run as non-root user. Doesn't solve self-created app vulnerabilities) These are mitigated by OCP's locked down default RBAC: * Writable host-path (host-path locked down by default. Not sure why host-path is special here though, seems like any PV could be used for persistence) * Privileged container (also locked down, admin must enable for a user/service account) * host-path mount (specifically for getting access to the file system, OCP locks down this via RBAC by default. Layer on SELinux to prevent an escalation from allowing file-system access) * list kubernetes secrets (RBAC to limit scope, and additionally a node can only access secrets for pods scheduled to it, in case node is exploited) * access container service-account (default service-account has pretty limited permissions) * access Kubernetes dashboard (containers have no special access to the console, which requires auth) These are just miscellaneous config/security controls: * Exposed dashboard (OCP console has authentication by default, no default passwords) * clear container-logs (built in log aggregation would require an additional exploit to defeat) * cluster internal networking (depends on the sdn plugin, but most installs limit networking to containers in the same namespace by default) * access tiller endpoint (No Helm 2, support for Helm 3 without tiller coming soon. Driven by tiller security/RBAC concerns)