Zero Trust Networking

Author: ahardin-rh

_topic_maps/_topic_map.yml

@@ -1257,6 +1257,8 @@ Topics:
   File: about-networking
 - Name: Understanding networking
   File: understanding-networking
+- Name: Zero trust networking
+  File: zero-trust-networking
 - Name: Accessing hosts
   File: accessing-hosts
 - Name: Networking Operators overview

networking/zero-trust-networking.adoc

@@ -0,0 +1,119 @@
+:_content-type: ASSEMBLY
+[id="zero-trust-networking"]
+= Zero trust networking
+include::_attributes/common-attributes.adoc[]
+:context: zero-trust-networking
+
+toc::[]
+
+
+Zero trust is an approach to designing security architectures based on the premise that every interaction begins in an untrusted state. This contrasts with traditional architectures, which might determine trustworthiness based on whether communication starts inside a firewall. More specifically, zero trust attempts to close gaps in security architectures that rely on implicit trust models and one-time authentication.
+
+{product-title} can add some zero-trust networking capabilities to containers running on the platform without requiring changes to the containers or the software running in them. There are also several products that Red Hat offers that can further augment the zero-trust networking capabilities of containers. If  you have the ability to change the software running in the containers, then there are other projects that Red Hat supports that can add further capabilities.
+
+Explore the following targeted capabilities of zero trust networking.
+
+[id="root-of-trust"]
+== Root of trust
+
+Public certificates and private keys are critical to zero-trust networking. These are used to identify components to one another, authenticate, and to secure traffic. The certificates are signed by other certificates, and there is a chain of trust to a root certificate authority (CA). Everything participating in the network needs to ultimately have the public key for a root CA so that it can validate the chain of trust. For public-facing things, these are usually the set of root CAs that are globally known, and whose keys are distributed with operating systems, web browsers, and so on. However, it is possible to run a private CA for a cluster or a corporation if the certificate of the private CA is distributed to all parties.
+
+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.
+
+[id="zero-trust-traffic-authentication-and-encryption"]
+== Traffic authentication and encryption
+
+Ensure that all traffic on the wire is encrypted and the endpoints are identifiable. An example of this is Mutual TLS, or mTLS, which is a method for mutual authentication.
+
+Leverage:
+
+* {product-title}: With transparent xref:../networking/ovn_kubernetes_network_provider/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/ovn_kubernetes_network_provider/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
+
+After you have the ability to mint certificates using a CA, you can use it to establish trust relationships by verification of the identity of the other end of a connection -- either a user or a client machine. This also requires management of certificate lifecycles to limit use if compromised.
+
+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.
+
+[id="zero-trust-inter-service-authorization"]
+== Inter-service authorization
+
+It is critical to be able to control access to services based on the identity of the requester. This is done by the platform and does not require each application to implement it. That allows better auditing and inspection of the policies.
+
+Leverage:
+
+* {product-title}: Can enforce isolation in the networking layer of the platform using the Kubernetes xref:../networking/network_policy/about-network-policy.adoc#about-network-policy[`NetworkPolicy`] and xref:../networking/ovn_kubernetes_network_provider/ovn-k-network-policy.adoc#adminnetworkpolicy_ovn-k-network-policy[`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
+
+In addition to the ability to identify and authenticate connections, it is also useful to control access to individual transactions. This can include rate-limiting by source, observability, and semantic validation that a transaction is well formed.
+
+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.
+
+[id="zero-trust-risk-assessment"]
+== Risk assessment
+
+As the number of security policies in a cluster increase, visualization of what the policies allow and deny becomes increasingly important. These tools make it easier to create, visualize, and manage cluster security policies.
+
+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].
+* 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"]
+== Sitewide Policy enforcement and distribution
+
+After deploying applications on a cluster, it becomes challenging to manage all of the objects that make up the security rules. It becomes critical to be able to apply site-wide policies and audit the deployed objects for compliance with the policies. This should allow for delegation of some permissions to users and cluster administrators within defined bounds, and should allow for exceptions to the policies if necessary.
+
+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.
+* 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.
+
+[id="zero-trust-observability-for-constant-retrospective-evaluation"]
+== Observability for constant, and retrospective, evaluation
+
+After you have a running cluster, you want to be able to observe the traffic and verify that the traffic comports with the defined rules. This is important for intrusion detection, forensics, and is helpful for operational load management.
+
+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.
+* 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.
+
+[id="zero-trust-endpoint-security"]
+== Endpoint security
+
+It is important to be able to trust that the software running the services in your cluster has not been compromised. For example, you might need to ensure that certified images are run on trusted hardware, and have policies to only allow connections to or from an endpoint based on endpoint characteristics.
+
+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].
+* 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"]
+== Extending trust outside the cluster
+
+You might want to extend trust outside the cluster by allowing a cluster to mint CAs for a subdomain. Alternatively, you might want to attest to workload identity in the cluster to a remote endpoint.
+
+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.