mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
65 lines
4.2 KiB
Plaintext
65 lines
4.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * scalability_and_performance/telco_core_ref_design_specs/telco-core-rds.adoc
|
|
|
|
:_mod-docs-content-type: REFERENCE
|
|
[id="telco-core-security_{context}"]
|
|
= Security
|
|
|
|
New in this release::
|
|
* No reference design updates in this release.
|
|
|
|
Description::
|
|
+
|
|
--
|
|
Telco customers are security conscious and require clusters to be hardened against multiple attack vectors.
|
|
In {product-title}, there is no single component or feature responsible for securing a cluster.
|
|
Described below are various security oriented features and configurations for the use models covered in the telco core RDS.
|
|
|
|
* **SecurityContextConstraints (SCC)**: All workload pods should be run with `restricted-v2` or `restricted` SCC.
|
|
* **Seccomp**: All pods should run with the `RuntimeDefault` (or stronger) seccomp profile.
|
|
* **Rootless DPDK pods**: Many user-plane networking (DPDK) CNFs require pods to run with root privileges.
|
|
With this feature, a conformant DPDK pod can be run without requiring root privileges.
|
|
Rootless DPDK pods create a tap device in a rootless pod that injects traffic from a DPDK application to the kernel.
|
|
* **Storage**: The storage network should be isolated and non-routable to other cluster networks.
|
|
See the "Storage" section for additional details.
|
|
|
|
See the Red Hat Knowledgebase solution article link:https://access.redhat.com/articles/7090422[Custom nftable firewall rules in OpenShift] for a supported method for implementing custom nftables firewall rules in {product-title} cluster nodes. This article is intended for cluster administrators who are responsible for managing network security policies in {product-title} environments.
|
|
|
|
It is crucial to carefully consider the operational implications before deploying this method, including:
|
|
|
|
* **Early application**: The rules are applied at boot time, before the network is fully operational.
|
|
Ensure the rules don't inadvertently block essential services required during the boot process.
|
|
* **Risk of misconfiguration**: Errors in your custom rules can lead to unintended consequences, potentially leading to performance impact or blocking legitimate traffic or isolating nodes.
|
|
Thoroughly test your rules in a non-production environment before deploying them to your main cluster.
|
|
* **External endpoints**: {product-title} requires access to external endpoints to function.
|
|
For more information about the firewall allowlist, see "Configuring your firewall for {product-title}". Ensure that cluster nodes are permitted access to those endpoints.
|
|
* **Node reboot**: Unless node disruption policies are configured, applying the `MachineConfig` CR with the required firewall settings causes a node reboot.
|
|
Be aware of this impact and schedule a maintenance window accordingly. For more information, see "Using node disruption policies to minimize disruption from machine config changes".
|
|
+
|
|
[NOTE]
|
|
====
|
|
Node disruption policies are available in {product-title} 4.17 and later.
|
|
====
|
|
|
|
* **Network flow matrix**: For more information about managing ingress traffic, see {product-title} network flow matrix.
|
|
You can restrict ingress traffic to essential flows to improve network security.
|
|
The matrix provides insights into base cluster services but excludes traffic generated by Day-2 Operators.
|
|
|
|
* **Cluster version updates and upgrades**: Exercise caution when updating or upgrading {product-title} clusters.
|
|
Recent changes to the platform's firewall requirements might require adjustments to network port permissions.
|
|
While the documentation provides guidelines, note that these requirements can evolve over time.
|
|
To minimize disruptions, you should test any updates or upgrades in a staging environment before applying them in production.
|
|
This helps you to identify and address potential compatibility issues related to firewall configuration changes.
|
|
--
|
|
|
|
Limits and requirements::
|
|
* Rootless DPDK pods requires the following additional configuration:
|
|
** Configure the `container_t` SELinux context for the tap plugin.
|
|
** Enable the `container_use_devices` SELinux boolean for the cluster host
|
|
|
|
Engineering considerations::
|
|
* For rootless DPDK pod support, enable the SELinux `container_use_devices` boolean on the host to allow the tap device to be created.
|
|
This introduces an acceptable security risk.
|
|
|