edit

Author: ahardin-rh

networking/zero-trust-networking.adoc

@@ -9,19 +9,19 @@ 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.
+{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.
+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.
+* 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
@@ -76,7 +76,7 @@ Leverage:
 * 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
+== Site-wide 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.
 
@@ -109,9 +109,9 @@ Leverage:
 * 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
+== Extending trust outside of 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.
+You might want to extend trust outside of 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: