mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OSDOCS-12729: Moved ZT to network security section
This commit is contained in:
committed by
openshift-cherrypick-robot
parent
441a9e2bdc
commit
8bce17e09c
@@ -1344,8 +1344,6 @@ Distros: openshift-enterprise,openshift-origin
|
||||
Topics:
|
||||
- Name: Understanding networking
|
||||
File: understanding-networking
|
||||
- Name: Zero trust networking
|
||||
File: zero-trust-networking
|
||||
- Name: Accessing hosts
|
||||
File: accessing-hosts
|
||||
- Name: Networking dashboards
|
||||
@@ -1488,6 +1486,8 @@ Topics:
|
||||
File: configuring-egress-firewall-ovn
|
||||
- Name: Configuring IPsec encryption
|
||||
File: configuring-ipsec-ovn
|
||||
- Name: Zero trust networking
|
||||
File: zero-trust-networking
|
||||
- Name: Configuring the Ingress Controller for manual DNS management
|
||||
File: ingress-controller-dnsmgt
|
||||
Distros: openshift-enterprise,openshift-origin
|
||||
|
||||
@@ -20,8 +20,8 @@ Public certificates and private keys are critical to zero trust networking. Thes
|
||||
|
||||
Leverage:
|
||||
|
||||
* {product-title}: OpenShift creates a xref:../security/certificate_types_descriptions/bootstrap-certificates.adoc#cert-types-bootstrap-certificates[cluster CA at installation] that is used to secure the cluster resources. However, {product-title} can also create and sign xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[certificates for services] in the cluster, and can inject the cluster CA bundle into a pod if requested. xref:../security/certificate_types_descriptions/service-ca-certificates.adoc#cert-types-service-ca-certificates[Service certificates] created and signed by {product-title} have a 26-month time to live (TTL) and are rotated automatically at 13 months. They can also be rotated manually if necessary.
|
||||
* xref:../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: cert-manager allows you to request keys that are signed by an external root of trust. There are many configurable issuers to integrate with external issuers, along with ways to run with a delegated signing certificate. The cert-manager API can be used by other software in zero trust networking to request the necessary certificates (for example, {SMProductName}), or can be used directly by customer software.
|
||||
* {product-title}: OpenShift creates a xref:../../security/certificate_types_descriptions/bootstrap-certificates.adoc#cert-types-bootstrap-certificates[cluster CA at installation] that is used to secure the cluster resources. However, {product-title} can also create and sign xref:../../security/certificates/service-serving-certificate.adoc#add-service-serving[certificates for services] in the cluster, and can inject the cluster CA bundle into a pod if requested. xref:../../security/certificate_types_descriptions/service-ca-certificates.adoc#cert-types-service-ca-certificates[Service certificates] created and signed by {product-title} have a 26-month time to live (TTL) and are rotated automatically at 13 months. They can also be rotated manually if necessary.
|
||||
* xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: cert-manager allows you to request keys that are signed by an external root of trust. There are many configurable issuers to integrate with external issuers, along with ways to run with a delegated signing certificate. The cert-manager API can be used by other software in zero trust networking to request the necessary certificates (for example, {SMProductName}), or can be used directly by customer software.
|
||||
|
||||
[id="zero-trust-traffic-authentication-and-encryption"]
|
||||
== Traffic authentication and encryption
|
||||
@@ -30,9 +30,9 @@ Ensure that all traffic on the wire is encrypted and the endpoints are identifia
|
||||
|
||||
Leverage:
|
||||
|
||||
* {product-title}: With transparent xref:../networking/network_security/configuring-ipsec-ovn.adoc#configuring-ipsec-ovn-pod-to-pod-ipsec[pod-to-pod IPsec], the source and destination of the traffic can be identified by the IP address. There is the capability for egress traffic to be xref:../networking/network_security/configuring-ipsec-ovn.adoc#nw-ovn-ipsec-north-south-enable_configuring-ipsec-ovn[encrypted using IPsec]. By using the xref:../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc#configuring-egress-ips-ovn[egress IP] feature, the source IP address of the traffic can be used to identify the source of the traffic inside the cluster.
|
||||
* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Provides powerful xref:../service_mesh/v2x/ossm-security.adoc#ossm-security-mtls_ossm-security[mTLS capabilities] that can transparently augment traffic leaving a pod to provide authentication and encryption.
|
||||
* xref:../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Use custom resource definitions (CRDs) to request certificates that can be mounted for your programs to use for SSL/TLS protocols.
|
||||
* {product-title}: With transparent xref:../../networking/network_security/configuring-ipsec-ovn.adoc#configuring-ipsec-ovn-pod-to-pod-ipsec[pod-to-pod IPsec], the source and destination of the traffic can be identified by the IP address. There is the capability for egress traffic to be xref:../../networking/network_security/configuring-ipsec-ovn.adoc#nw-ovn-ipsec-north-south-enable_configuring-ipsec-ovn[encrypted using IPsec]. By using the xref:../../networking/ovn_kubernetes_network_provider/configuring-egress-ips-ovn.adoc#configuring-egress-ips-ovn[egress IP] feature, the source IP address of the traffic can be used to identify the source of the traffic inside the cluster.
|
||||
* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Provides powerful xref:../../service_mesh/v2x/ossm-security.adoc#ossm-security-mtls_ossm-security[mTLS capabilities] that can transparently augment traffic leaving a pod to provide authentication and encryption.
|
||||
* xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Use custom resource definitions (CRDs) to request certificates that can be mounted for your programs to use for SSL/TLS protocols.
|
||||
|
||||
[id="zero-trust-identification-and-authentication"]
|
||||
== Identification and authentication
|
||||
@@ -41,10 +41,10 @@ After you have the ability to mint certificates using a CA, you can use it to es
|
||||
|
||||
Leverage:
|
||||
|
||||
* {product-title}: Cluster-signed xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[service certificates] to ensure that a client is talking to a trusted endpoint. This requires that the service uses SSL/TLS and that the client uses the xref:../security/certificates/service-serving-certificate.adoc#add-service-certificate-configmap_service-serving-certificate[cluster CA]. The client identity must be provided using some other means.
|
||||
* xref:../security/container_security/security-platform.adoc#security-platform-red-hat-sso_security-platform[Red Hat Single Sign-On]: Provides request authentication integration with enterprise user directories or third-party identity providers.
|
||||
* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: xref:../service_mesh/v2x/ossm-architecture.adoc#ossm-architecture[Transparent upgrade] of connections to mTLS, auto-rotation, custom certificate expiration, and request authentication with JSON web token (JWT).
|
||||
* xref:../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Creation and management of certificates for use by your application. Certificates can be controlled by CRDs and mounted as secrets, or your application can be changed to interact directly with the cert-manager API.
|
||||
* {product-title}: Cluster-signed xref:../../security/certificates/service-serving-certificate.adoc#add-service-serving[service certificates] to ensure that a client is talking to a trusted endpoint. This requires that the service uses SSL/TLS and that the client uses the xref:../../security/certificates/service-serving-certificate.adoc#add-service-certificate-configmap_service-serving-certificate[cluster CA]. The client identity must be provided using some other means.
|
||||
* xref:../../security/container_security/security-platform.adoc#security-platform-red-hat-sso_security-platform[Red Hat Single Sign-On]: Provides request authentication integration with enterprise user directories or third-party identity providers.
|
||||
* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: xref:../../service_mesh/v2x/ossm-architecture.adoc#ossm-architecture[Transparent upgrade] of connections to mTLS, auto-rotation, custom certificate expiration, and request authentication with JSON web token (JWT).
|
||||
* xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: Creation and management of certificates for use by your application. Certificates can be controlled by CRDs and mounted as secrets, or your application can be changed to interact directly with the cert-manager API.
|
||||
|
||||
[id="zero-trust-inter-service-authorization"]
|
||||
== Inter-service authorization
|
||||
@@ -53,8 +53,8 @@ It is critical to be able to control access to services based on the identity of
|
||||
|
||||
Leverage:
|
||||
|
||||
* {product-title}: Can enforce isolation in the networking layer of the platform using the Kubernetes xref:../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[`NetworkPolicy`] and xref:../networking/network_security/AdminNetworkPolicy/ovn-k-anp.adoc#ovn-k-anp[`AdminNetworkPolicy`] objects.
|
||||
* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Sophisticated L4 and L7 xref:../service_mesh/v2x/ossm-security.adoc#ossm-security[control of traffic] using standard Istio objects and using mTLS to identify the source and destination of traffic and then apply policies based on that information.
|
||||
* {product-title}: Can enforce isolation in the networking layer of the platform using the Kubernetes xref:../../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[`NetworkPolicy`] and xref:../../networking/network_security/AdminNetworkPolicy/ovn-k-anp.adoc#ovn-k-anp[`AdminNetworkPolicy`] objects.
|
||||
* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Sophisticated L4 and L7 xref:../../service_mesh/v2x/ossm-security.adoc#ossm-security[control of traffic] using standard Istio objects and using mTLS to identify the source and destination of traffic and then apply policies based on that information.
|
||||
|
||||
[id="zero-trust-transaction-level-verification"]
|
||||
== Transaction-level verification
|
||||
@@ -63,7 +63,7 @@ In addition to the ability to identify and authenticate connections, it is also
|
||||
|
||||
Leverage:
|
||||
|
||||
* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Perform L7 inspection of requests, rejecting malformed HTTP requests, transaction-level xref:../service_mesh/v2x/ossm-architecture.adoc#understanding-kiali[observability and reporting]. {SMProductShortName} can also provide xref:../service_mesh/v2x/ossm-security.adoc#restrict-access-with-json-web-token[request-based authentication] using JWT.
|
||||
* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Perform L7 inspection of requests, rejecting malformed HTTP requests, transaction-level xref:../../service_mesh/v2x/ossm-architecture.adoc#understanding-kiali[observability and reporting]. {SMProductShortName} can also provide xref:../../service_mesh/v2x/ossm-security.adoc#restrict-access-with-json-web-token[request-based authentication] using JWT.
|
||||
|
||||
[id="zero-trust-risk-assessment"]
|
||||
== Risk assessment
|
||||
@@ -72,7 +72,7 @@ As the number of security policies in a cluster increase, visualization of what
|
||||
|
||||
Leverage:
|
||||
|
||||
* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Create and visualize Kubernetes `NetworkPolicy` and `AdminNetworkPolicy`, and OpenShift Networking `EgressFirewall` objects using the xref:../web_console/web-console-overview.adoc#web-console-overview[OpenShift web console].
|
||||
* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Create and visualize Kubernetes `NetworkPolicy` and `AdminNetworkPolicy`, and OpenShift Networking `EgressFirewall` objects using the xref:../../web_console/web-console-overview.adoc#web-console-overview[OpenShift web console].
|
||||
* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes]: Advanced link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_security_for_kubernetes/4.3/html/operating/index[visualization of objects].
|
||||
|
||||
[id="zero-trust-sitewide-policy-enforcement-and-distribution"]
|
||||
@@ -82,7 +82,7 @@ After deploying applications on a cluster, it becomes challenging to manage all
|
||||
|
||||
Leverage:
|
||||
|
||||
* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: RBAC to xref:../security/container_security/security-platform.adoc#security-platform-multi-tenancy_security-platform[control policy object]s and delegate control.
|
||||
* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: RBAC to xref:../../security/container_security/security-platform.adoc#security-platform-multi-tenancy_security-platform[control policy object]s and delegate control.
|
||||
* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes]: link:https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_security_for_kubernetes/4.1/html/operating/manage-security-policies#doc-wrapper[Policy enforcement] engine.
|
||||
* link:https://www.redhat.com/en/technologies/management/advanced-cluster-management[{rh-rhacm-first} for Kubernetes]: Centralized policy control.
|
||||
|
||||
@@ -93,10 +93,10 @@ After you have a running cluster, you want to be able to observe the traffic and
|
||||
|
||||
Leverage:
|
||||
|
||||
* xref:../observability/network_observability/installing-operators.adoc#installing-network-observability-operators[Network Observability Operator]: Allows for inspection, monitoring, and alerting on network connections to pods and nodes in the cluster.
|
||||
* xref:../../observability/network_observability/installing-operators.adoc#installing-network-observability-operators[Network Observability Operator]: Allows for inspection, monitoring, and alerting on network connections to pods and nodes in the cluster.
|
||||
* link:https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[{rh-rhacm-first} for Kubernetes]: Monitors, collects, and evaluates system-level events such as process execution, network connections and flows, and privilege escalation. It can determine a baseline for a cluster, and then detect anomalous activity and alert you about it.
|
||||
* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Can xref:../service_mesh/v2x/ossm-architecture.adoc#ossm-kiali-overview_ossm-architecture[monitor traffic] entering and leaving a pod.
|
||||
* xref:../service_mesh/v2x/ossm-architecture.adoc#understanding-distributed-tracing[{DTProductName}]: For suitably instrumented applications, you can see all traffic associated with a particular action as it splits into sub-requests to microservices. This allows you to identify bottlenecks within a distributed application.
|
||||
* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Can xref:../../service_mesh/v2x/ossm-architecture.adoc#ossm-kiali-overview_ossm-architecture[monitor traffic] entering and leaving a pod.
|
||||
* xref:../../service_mesh/v2x/ossm-architecture.adoc#understanding-distributed-tracing[{DTProductName}]: For suitably instrumented applications, you can see all traffic associated with a particular action as it splits into sub-requests to microservices. This allows you to identify bottlenecks within a distributed application.
|
||||
|
||||
[id="zero-trust-endpoint-security"]
|
||||
== Endpoint security
|
||||
@@ -105,7 +105,7 @@ It is important to be able to trust that the software running the services in yo
|
||||
|
||||
Leverage:
|
||||
|
||||
* {product-title}: Secureboot can ensure that the nodes in the cluster are running trusted software, so the platform itself (including the container runtime) have not been tampered with. You can configure {product-title} to only run images that have been xref:../security/container_security/security-container-signature.adoc#security-container-signature[signed by certain signatures].
|
||||
* {product-title}: Secureboot can ensure that the nodes in the cluster are running trusted software, so the platform itself (including the container runtime) have not been tampered with. You can configure {product-title} to only run images that have been xref:../../security/container_security/security-container-signature.adoc#security-container-signature[signed by certain signatures].
|
||||
* link:https://catalog.redhat.com/software/container-stacks/detail/6525b71aa53de2eb01ac9628[Red Hat Trusted Artifact Signer]: This can be used in a trusted build chain and produce signed container images.
|
||||
|
||||
[id="extending-trust-outside-the-cluster"]
|
||||
@@ -115,5 +115,5 @@ You might want to extend trust outside of the cluster by allowing a cluster to m
|
||||
|
||||
Leverage:
|
||||
|
||||
* xref:../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: You can use cert-manager to manage delegated CAs so that you can distribute trust across different clusters, or through your organization.
|
||||
* xref:../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Can use SPIFFE to provide remote attestation of workloads to endpoints running in remote or local clusters.
|
||||
* xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[OpenShift cert-manager Operator]: You can use cert-manager to manage delegated CAs so that you can distribute trust across different clusters, or through your organization.
|
||||
* xref:../../service_mesh/v2x/ossm-about.adoc#ossm-about[{SMProductName}]: Can use SPIFFE to provide remote attestation of workloads to endpoints running in remote or local clusters.
|
||||
@@ -242,7 +242,7 @@ Manage machines, provide services to users, and follow monitoring and logging re
|
||||
|
||||
- **xref:../authentication/understanding-authentication.adoc#understanding-authentication[Manage authentication]**: Learn how user, group, and API authentication works in {product-title}. {product-title} supports xref:../authentication/understanding-identity-provider.adoc#supported-identity-providers[multiple identity providers].
|
||||
|
||||
- **Manage xref:../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[ingress], xref:../security/certificates/api-server.adoc#api-server-certificates[API server], and xref:../security/certificates/service-serving-certificate.adoc#add-service-serving[service] certificates**: {product-title} creates certificates by default for the Ingress Operator, the API server, and for services needed by complex middleware applications that require encryption. You might need to change, add, or rotate these certificates.
|
||||
- **Manage xref:../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[ingress], xref:../security/certificates/api-server.adoc#api-server-certificates[API server], and xref:../../security/certificates/service-serving-certificate.adoc#add-service-serving[service] certificates**: {product-title} creates certificates by default for the Ingress Operator, the API server, and for services needed by complex middleware applications that require encryption. You might need to change, add, or rotate these certificates.
|
||||
|
||||
- **xref:../networking/understanding-networking.adoc#understanding-networking[Manage networking]**: The cluster network in {product-title} is managed by the xref:../networking/networking_operators/cluster-network-operator.adoc#nw-cluster-network-operator_cluster-network-operator[Cluster Network Operator] (CNO). The Multus Container Network Interface adds the capability to attach xref:../networking/multiple_networks/understanding-multiple-networks.adoc#understanding-multiple-networks[multiple network interfaces] to a pod. By using
|
||||
xref:../networking/network_security/network_policy/about-network-policy.adoc#about-network-policy[network policy] features, you can isolate your pods or permit selected traffic.
|
||||
|
||||
Reference in New Issue
Block a user