It is important to understand how to properly secure various aspects of your OKD cluster.
A good starting point to understanding OKD security is to review the concepts in Understanding container security. This and subsequent sections provide a high-level walkthrough of the container security measures available in OKD, including solutions for the host layer, the container and orchestration layer, and the build and application layer. These sections also include information on the following topics:
Why container security is important and how it compares with existing security standards.
Which container security measures are provided by the host (FCOS and Fedora) layer and which are provided by OKD.
How to evaluate your container content and sources for vulnerabilities.
How to design your build and deployment process to proactively check container content.
How to control access to containers through authentication and authorization.
How networking and attached storage are secured in OKD.
Containerized solutions for API management and SSO.
OKD auditing provides a security-relevant chronological set of records documenting the sequence of activities that have affected the system by individual users, administrators, or other components of the system. Administrators can configure the audit log policy and view audit logs.
Certificates are used by various components to validate access to the cluster. Administrators can replace the default ingress certificate, add API server certificates, or add a service certificate.
You can also review more details about the types of certificates used by the cluster:
Monitoring and cluster logging Operator component certificates
You can enable etcd encryption for your cluster to provide an additional layer of data security. For example, it can help protect the loss of sensitive data if an etcd backup is exposed to the incorrect parties.
Administrators can use the Red Hat Quay Container Security Operator to run vulnerability scans and review information about detected vulnerabilities.
For many OKD customers, regulatory readiness, or compliance, on some level is required before any systems can be put into production. That regulatory readiness can be imposed by national standards, industry standards, or the organization’s corporate governance framework.
Administrators can use the Compliance Operator to run compliance scans and recommend remediations for any issues found.
Administrators can use the File Integrity Operator to continually run file integrity checks on cluster nodes and provide a log of files that have been modified.