gnelson/ocp-docs-suggestions-1k-pr huggingface dataset:
Original: monitoring/monitoring-service[Deployment] => apps/internal-app-a[Deployment] : All Connections
##### Enabling policies: - [ANP] allow-all-internal-monitoring - [NP] apps/internal-app-a-monitor-access
monitoring/monitoring-service[Deployment] => third-party/external-service[Deployment] : All Connections
##### Enabling policies: - [ANP] allow-external-service-monitoring
Revised: Connections between monitoring/monitoring-service[Pod] => internal-apps/internal-app-a[Pod]:
Allowed connections:
Allowed TCP, UDP, SCTP due to the following policies and rules:
Egress (Allowed) due to the system default (Allow all)
Ingress (Allowed)
AdminNetworkPolicy 'pass-monitoring' passes connections by Ingress rule pass-ingress-from-monitoring
NetworkPolicy 'internal-apps/allow-monitoring' allows connections by Ingress rule #1
Original: * The connection from `monitoring/monitoring-service` to `apps/internal-app-a` is allowed by both a general Admin Network Policy `[ANP] allow-all-internal-monitoring` that applies broadly, and a more specific Network Policy `[NP] apps/internal-app-a-monitor-access` tailored for `internal-app-a`.
This shows multiple policies can contribute to allowing a connection.
* The connection from `monitoring/monitoring-service` to `third-party/external-service` is allowed by a specific Admin Network Policy `[ANP] allow-external-service-monitoring` that grants access to the external service for monitoring.
Revised: The connection from `monitoring/monitoring-service` to `internal-apps/internal-app-a` is allowed by the combination of Admin Network Policy [ANP] `pass-monitoring` that applies broadly on all namespaces with label `security: internal`, and a more specific Network Policy [NP]  `internal-apps/allow-monitoring`  tailored for `internal-app-a`. This shows multiple policies can contribute to allowing a connection.
Original: Consider an isolated data service `isolated-data-service` which is designed to deny all external access by default for security reasons.

The explainability output for blocked connections from the `monitoring-service` deployment might show:
Revised: 
Consider an isolated data service `isolated-data-service` which is designed to deny all external access by default for security reasons.
The YAML manifests for this example are available [here](https://github.com/np-guard/netpol-analyzer/tree/7ab6bbd421d3d80cbfff7cd1529ff8caf0137fbc/tests/anp_banp_explain_demo_2).


The explainability output for blocked connections from the `monitoring-service` deployment to this workload will show:
Original: monitoring/central-monitoring[Deployment] => data/isolated-data-service[Deployment] : No Connections
##### Blocking policies: - [ANP] block-all-external-access - [BANP] default-deny-egress
Revised: Connections between monitoring/monitoring-service[Pod] => isolated-apps/isolated-data-service[Pod]:

Denied connections:
Denied TCP, UDP, SCTP due to the following policies and rules:
Egress (Allowed) due to the system default (Allow all)
Ingress (Denied)
AdminNetworkPolicy 'pass-monitoring' passes connections by Ingress rule pass-ingress-from-monitoring
BaselineAdminNetworkPolicy 'default' denies connections by Ingress rule deny-ingress-from-monitoring
Original: In this example, the connection to `data/isolated-data-service` is blocked by two types of policies:

* An Admin Network Policy `[ANP] block-all-external-access` specifically configured to deny external connections to this sensitive service.
* A Baseline Admin Network Policy `[BANP] default-deny-egress` which is a foundational policy that denies all outgoing connections by default unless explicitly allowed by other rules.
Revised: In this example, the connection to `data/isolated-data-service` is blocked by a combination of ANP with Pass action, and of BANP that denies all connections from `monitoring` by default.
Original: * A network policy configuration that defines Admin Network Policy(ANP) to `pass` connections from monitoring into namespaces with label `security: internal`, and a specific Network Policy(NP) that explicitly allows connections from `monitoring-service` into `internal-app-a`.
Revised: * A network policy configuration that defines Admin Network Policy (ANP) to `pass` connections from monitoring into namespaces with label `security: internal`, and a specific Network Policy (NP) that explicitly allows connections from `monitoring-service` into `internal-app-a`.
Original: In this example:

The connection from `monitoring/monitoring-service` to `internal-apps/internal-app-a` is allowed by the combination of ANP `pass-monitoring` that applies broadly on all namespaces with the label `security: internal` and a more specific NP `internal-apps/allow-monitoring` tailored for `internal-app-a`. The output shows that multiple policies can contribute to allowing a connection.
Revised: In this example, the combination of ANP `pass-monitoring` allows the connection from `monitoring/monitoring-service` to `internal-apps/internal-app-a` that applies broadly on all namespaces with the label `security: internal` and a more specific NP `internal-apps/allow-monitoring` tailored for `internal-app-a`. The output shows that multiple policies can contribute to allowing a connection.
Original: You could inspect your containers for vulnerabilities and compliance issues
with link:https://anchore.com[Anchore] or Twistlock,
and use image scanning tools such as AtomicScan or Clair.
Tools such as link:https://sysdig.com[Sysdig] could provide ongoing monitoring
of your containerized applications.
Revised: You can inspect your containers for vulnerabilities and configuration issues at build, deploy, or runtime with https://www.redhat.com/en/technologies/cloud-computing/openshift/advanced-cluster-security-kubernetes[Red Hat Advanced Cluster Security for Kubernetes]. For images stored in Quay, you can use the https://access.redhat.com/products/red-hat-quay[Clair scanner] to inspect images at rest. In addition, there are https://catalog.redhat.com/software/vulnerability-scanner/search[certified vulnerability scanners] available in the Red Hat ecosystem catalog.
Original: Upgrading your cluster to {product-title} {product-version} when the `libreswan` and `NetworkManager-libreswan` packages differ between {product-title} versions leads to two consecutive compute node reboot operations. For the first reboot, the Cluster Network Operator (CNO) applies the IPsec configuration to compute nodes. For the second reboot, the Machine Config Operator (MCO) applies the latest machine configs to the cluster.
Revised: Upgrading your cluster to {product-title} {product-version} when the `libreswan` and `NetworkManager-libreswan` packages have different {product-title} versions causes two consecutive compute node reboot operations. For the first reboot, the Cluster Network Operator (CNO) applies the IPsec configuration to compute nodes. For the second reboot, the Machine Config Operator (MCO) applies the latest machine configs to the cluster.
Original: * link:https://www.pagerduty.com/[PagerDuty] (PagerDuty official site)
* link:https://www.pagerduty.com/docs/guides/prometheus-integration-guide/[Prometheus Integration Guide] (PagerDuty official site)
Revised: * link:https://www.pagerduty.com/docs/guides/prometheus-integration-guide/[Prometheus Integration Guide] (PagerDuty documentation)
Original: * Before this update, the {gitops-title} Operator did not correctly handle regular expressions in `sourceNamespaces`, leading to an unexpected behavior when matching namespace patterns. With this update, thethe {gitops-title} Operator now uses the correct regex option, `glob.REGEXP`, instead of `glob.GLOB` when processing `getSourceNamespaces`, ensuring that regular expressions are evaluated and matched accurately. link:https://issues.redhat.com/browse/GITOPS-6675[GITOPS-6675]
Revised: * Before this update, the {gitops-title} Operator did not correctly handle regular expressions in `sourceNamespaces`, leading to an unexpected behavior when matching namespace patterns. With this update, the {gitops-title} Operator now uses the correct regex option, `glob.REGEXP`, instead of `glob.GLOB` when processing `getSourceNamespaces`, ensuring that regular expressions are evaluated and matched accurately. link:https://issues.redhat.com/browse/GITOPS-6675[GITOPS-6675]
Original: * Before this update, the `gitops-plugin` Deployment created by the {gitops-title} Operator did not include a security context, causing the plugin Pod to fail in environments that enforce the PodSecurity restricted policy. With this update, the {gitops-title} Operator now sets the required security context for the `gitops-plugin` Deployment, ensuring compliance with the PodSecurity restricted policy. link:https://issues.redhat.com/browse/GITOPS-6777[GITOPS-6777]
Revised: * Before this update, the `gitops-plugin` deployment created by the {gitops-title} Operator did not include a security context, causing the plugin pod to fail in environments that enforce the `PodSecurity` restricted policy. With this update, the {gitops-title} Operator now sets the required security context for the `gitops-plugin` deployment, ensuring compliance with the `PodSecurity` restricted policy. link:https://issues.redhat.com/browse/GITOPS-6777[GITOPS-6777]
Original: * Before this update, Argo CD monitoring worked automatically when deployed in any namespace and user-workload monitoring support for workloads did not require any manual configuration. With this update, if you deploy Argo CD in a non-{OCP} namespace, you must enable user-workload monitoring in {OCP}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/monitoring/configuring-user-workload-monitoring#configurable-monitoring-components_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-7037[GITOPS-7037]
Revised: * Before this update, Argo CD monitoring worked automatically when deployed in any namespace and user-workload monitoring support for workloads did not require any manual configuration. With this update, if you deploy Argo CD in a non-{OCP} namespace, you must enable user-workload monitoring in {OCP}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/monitoring/configuring-user-workload-monitoring#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]. link:https://issues.redhat.com/browse/GITOPS-7037[GITOPS-7037]
* Before this update, Argo CD monitoring worked automatically when deployed in any namespace and user-workload monitoring support for workloads did not require any manual configuration. With this update, if you deploy Argo CD in a non-{OCP} namespace, you must enable user-workload monitoring in {OCP}. For more information, see link:https://docs.redhat.com/en/documentation/openshift_container_platform/latest/html/monitoring/configuring-user-workload-monitoring#configurable-monitoring-components_preparing-to-configure-the-monitoring-stack-uwm[Configurable monitoring components]. link:https://issues.redhat.com/browse/GITOPS-7037[GITOPS-7037]
Original: |`certificateSecret`
|The `certificateSecret` value is a reference to a secret that contains the default certificate that is served by the ingress controller. When routes do not specify their own certificate, `certificateSecret` is used.

The secret must contain the following keys and data:
* `tls.crt`: certificate file contents
* `tls.key`: key file contents
Revised: |A reference to a `kubernetes.io/tls` type of secret that contains the default certificate that is served by the {microshift-short} ingress controller. When routes do not specify their own certificate, the `certificateSecret` parameter is used. All secrets used must contain `tls.key` key file contents and `tls.crt` certificate file contents.
Original: |`certificateSecret`
|The `certificateSecret` value is a reference to a secret that contains the default certificate that is served by the ingress controller. When routes do not specify their own certificate, `certificateSecret` is used.

The secret must contain the following keys and data:
* `tls.crt`: certificate file contents
* `tls.key`: key file contents
If not set, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains`, and the generated certificate's CA is automatically integrated with the cluster's truststore.
The in-use certificate, whether generated or user-specified, is automatically integrated with {microshift-short} built-in OAuth server.
|`clientTLS` authenticates client access to the cluster and services. As a result, mutual TLS authentication is enabled. If not set, then client TLS is not enabled.
`clientTLS` has the required subfields, `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA`.
The `ClientCertificatePolicy` subfield accepts one of the two values: `Required` or `Optional`. The ingress controller only checks client certificates for edge-terminated and re-encrypted TLS routes. The ingress controller cannot check certificates for plain text HTTP or passthrough TLS routes.
Revised: |Specifies a required config map that is in the `openshift-ingress` namespace. Required to enable client TLS. The config map must contain a certificate authority (CA) bundle.
Original: |`certificateSecret`
|The `certificateSecret` value is a reference to a secret that contains the default certificate that is served by the ingress controller. When routes do not specify their own certificate, `certificateSecret` is used.

The secret must contain the following keys and data:
* `tls.crt`: certificate file contents
* `tls.key`: key file contents
If not set, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains`, and the generated certificate's CA is automatically integrated with the cluster's truststore.
The in-use certificate, whether generated or user-specified, is automatically integrated with {microshift-short} built-in OAuth server.
|`clientTLS` authenticates client access to the cluster and services. As a result, mutual TLS authentication is enabled. If not set, then client TLS is not enabled.
Revised: |Optional subfield that specifies a list of regular expressions that are matched against the distinguished name on a valid client certificate to filter requests. Use this parameter to cause the ingress controller to reject certificates based on the distinguished name. The Perl Compatible Regular Expressions (PCRE) syntax is required.
Original: |`certificateSecret`
|The `certificateSecret` value is a reference to a secret that contains the default certificate that is served by the ingress controller. When routes do not specify their own certificate, `certificateSecret` is used.

The secret must contain the following keys and data:
* `tls.crt`: certificate file contents
* `tls.key`: key file contents
If not set, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains`, and the generated certificate's CA is automatically integrated with the cluster's truststore.
The in-use certificate, whether generated or user-specified, is automatically integrated with {microshift-short} built-in OAuth server.
|`clientTLS` authenticates client access to the cluster and services. As a result, mutual TLS authentication is enabled. If not set, then client TLS is not enabled.
Revised: |Authenticates client access to the cluster and services. As a result, mutual TLS authentication is enabled. If not set, client TLS is not enabled. You must set the `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA` parameters to use client TLS.
Original: |`certificateSecret`
|The `certificateSecret` value is a reference to a secret that contains the default certificate that is served by the ingress controller. When routes do not specify their own certificate, `certificateSecret` is used.

The secret must contain the following keys and data:
* `tls.crt`: certificate file contents
* `tls.key`: key file contents
If not set, a wildcard certificate is automatically generated and used. The certificate is valid for the ingress controller `domain` and `subdomains`, and the generated certificate's CA is automatically integrated with the cluster's truststore.
The in-use certificate, whether generated or user-specified, is automatically integrated with {microshift-short} built-in OAuth server.
|`clientTLS` authenticates client access to the cluster and services. As a result, mutual TLS authentication is enabled. If not set, then client TLS is not enabled.
`clientTLS` has the required subfields, `spec.clientTLS.clientCertificatePolicy` and `spec.clientTLS.ClientCA`.
The `ClientCertificatePolicy` subfield accepts one of the two values: `Required` or `Optional`. The ingress controller only checks client certificates for edge-terminated and re-encrypted TLS routes. The ingress controller cannot check certificates for plain text HTTP or passthrough TLS routes.
The `ClientCA` subfield specifies a config map that is in the openshift-ingress namespace. The config map should contain a CA certificate bundle. A config map is required for this field.
The `AllowedSubjectPatterns` is an optional value that specifies a list of regular expressions, which are matched against the distinguished name on a valid client certificate to filter requests. The regular expressions must use PCRE syntax. This field must contain a valid expression or the MicroShift service fails. At least one pattern must match a client certificate's distinguished name; otherwise, the ingress controller rejects the certificate and denies the connection. If the field value is not set, the ingress controller does not reject certificates based on the distinguished name.
Revised: |`Required` or `Optional` are valid values. Set to `Required` to enable client TLS. The ingress controller only checks client certificates for edge-terminated and re-encrypted TLS routes. The ingress controller cannot check certificates for plain text HTTP or passthrough TLS routes.
Original: * `Append`, preserves any existing headers by specifying that the ingress controller appends them.
* `Replace`, removes any existing headers by specifying that the ingress controller sets the headers.
* `Never`, preserves any existing headers by specifying that the ingress controller never sets the headers.
* `httpCompressionmimeTypes` defines a list of MIME types to which compression should be applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`. The `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
Revised: |`httpCompression.mimeTypes`
|Defines a list of MIME types to which compression should be applied, in the `type/subtype; [;attribute=value]` format.

* For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`.
* Valid `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
Original: * `Append`, preserves any existing headers by specifying that the ingress controller appends them.
* `Replace`, removes any existing headers by specifying that the ingress controller sets the headers.
* `Never`, preserves any existing headers by specifying that the ingress controller never sets the headers.
* `httpCompressionmimeTypes` defines a list of MIME types to which compression should be applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`. The `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
|`httpEmptyRequestsPolicy` describes how HTTP connections are handled if the connection times out before a request is received. Allowed values for this field are `Respond` and `Ignore`. The default value is `Respond`.
Revised: |Describes how HTTP connections are handled if the connection times out before a request is received. Allowed values for this field are `Respond` and `Ignore`. The default value is `Respond`. Empty requests typically come from load-balancer health probes or preconnects and can often be safely ignored. However, these requests can also be caused by network errors and port scans. As such, setting this field to `Ignore` can impede detection or diagnosis of network problems and detecting intrusion attempts.
Original: * `Append`, preserves any existing headers by specifying that the ingress controller appends them.
* `Replace`, removes any existing headers by specifying that the ingress controller sets the headers.
* `Never`, preserves any existing headers by specifying that the ingress controller never sets the headers.
* `httpCompressionmimeTypes` defines a list of MIME types to which compression should be applied. For example, `text/css; charset=utf-8`, `text/html`, `text/*`, `image/svg+xml`, `application/octet-stream`, `X-custom/customsub`, using the format pattern, `type/subtype; [;attribute=value]`. The `types` are: application, image, message, multipart, text, video, or a custom type prefaced by `X-`. To see the full notation for MIME types and subtypes, see link:https://datatracker.ietf.org/doc/html/rfc1341#page-7[RFC1341] (IETF Datatracker documentation).
|`httpEmptyRequestsPolicy` describes how HTTP connections are handled if the connection times out before a request is received. Allowed values for this field are `Respond` and `Ignore`. The default value is `Respond`.
The `httpEmptyRequestsPolicy` type accepts either one of two values:
* `Respond`: If the field is set to `Respond`, the ingress controller sends an HTTP `400` or `408` response, logs the connection if access logging is enabled, and counts the connection in the appropriate metrics.
* `Ignore`: Setting the option to `Ignore` adds the `http-ignore-probes` parameter in the `HAproxy` configuration. If the field is set to `Ignore`, the ingress controller closes the connection without sending a response, then logs the connection, or incrementing metrics.
Revised: |Specifies connections for which no request is received and logged. `Log` and `Ignore` are valid values. Empty requests typically come from load-balancer health probes or preconnects and can often be safely ignored. However, these requests can also be caused by network errors and port scans. As such, setting this field to `Ignore` can impede detection or diagnosis of network problems and detecting intrusion attempts. The default value is `Log`.
Original: = About integrating Service Mesh with cert-manager and istio-csr
//TP1 content influx. Title, etc may change.
The cert-manager tool provides integration with Istio through an external agent called `istio-csr`. The `istio-csr` agent handles certificate signing requests (CSR) from Istio proxies and the `controlplane` in the following ways:
. Verifying the identity of the workload.
. Creating a CSR through cert-manager for the workload.
The cert-manager tool then creates a CSR to the configured CA Issuer, which signs the certificate.
Revised: By integrating {istio} with the `istio-csr` agent that is managed by the cert-manager Operator, you enable {istio} to request and manage the certificates directly. The integration simplifies security configuration and centralizes certificate management within the cluster.