Prerequisites

• You must have a certificate/key pair in PEM-encoded files, where the certificate is signed by a trusted certificate authority or by a private trusted certificate authority that you configured in a custom PKI.

• Your certificate meets the following requirements:

  • The certificate is valid for the ingress domain.
  • The certificate uses the subjectAltName extension to specify a wildcard domain, such as *.apps.ocp4.example.com.

• You must have an IngressController CR. You may use the default one:

  $ oc --namespace openshift-ingress-operator get ingresscontrollers

  Example output

  NAME      AGE
  default   10m

Prerequisites

• You have access to the cluster as a user with the cluster-admin role.
• You have installed the OpenShift CLI (oc).
• You previously configured a custom default certificate for the Ingress Controller.

Procedure

• To remove the custom certificate and restore the certificate that ships with Red Hat OpenShift Service on AWS, enter the following command:

  $ oc patch -n openshift-ingress-operator ingresscontrollers/default \
    --type json -p $'- op: remove\n  path: /spec/defaultCertificate'

  There can be a delay while the cluster reconciles the new certificate configuration.

Verification

• To confirm that the original cluster certificate is restored, enter the following command:

  $ echo Q | \
    openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
    openssl x509 -noout -subject -issuer -enddate

  where:

  <domain>

  Specifies the base domain name for your cluster.

  Example output

  subject=CN = *.apps.<domain>
  issuer=CN = ingress-operator@1620633373
  notAfter=May 10 10:44:36 2023 GMT

Verification

• Verify that the default Ingress Controller is scaled out to match the value returned by the kube-state-metrics query by running the following commands:

  • Use the grep command to search the Ingress Controller YAML file for replicas:

    $ oc get ingresscontroller/default -o yaml | grep replicas:

    Example output

    replicas: 3

  • Get the pods in the openshift-ingress project:

    $ oc get pods -n openshift-ingress

    Example output

    NAME                             READY   STATUS    RESTARTS   AGE
    router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
    router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
    router-default-7b5df44ff-wwsth   2/2     Running   0          66s

Prerequisites

• Log in as a user with cluster-admin privileges.

• To configure Ingress access logging, you must specify a destination using spec.logging.access.destination. To specify logging to a sidecar container, you must specify Container spec.logging.access.destination.type. The following example is an Ingress Controller definition that logs to a Container destination:

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Container

• When you configure the Ingress Controller to log to a sidecar, the operator creates a container named logs inside the Ingress Controller Pod:

  $ oc -n openshift-ingress logs deployment.apps/router-default -c logs

  Example output

  2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

• To configure Ingress access logging, you must specify a destination using spec.logging.access.destination. To specify logging to a Syslog endpoint destination, you must specify Syslog for spec.logging.access.destination.type. If the destination type is Syslog, you must also specify a destination endpoint using spec.logging.access.destination.syslog.endpoint and you can specify a facility using spec.logging.access.destination.syslog.facility. The following example is an Ingress Controller definition that logs to a Syslog destination:

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Syslog
          syslog:
            address: 1.2.3.4
            port: 10514

  Note

  The syslog destination port must be UDP.

• You can specify spec.logging.access.httpLogFormat to customize the log format. The following example is an Ingress Controller definition that logs to a syslog endpoint with IP address 1.2.3.4 and port 10514:

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Syslog
          syslog:
            address: 1.2.3.4
            port: 10514
        httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

• To disable Ingress access logging, leave spec.logging or spec.logging.access empty:

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access: null

• Use spec.logging.access.destination.syslog.maxLength if you are using spec.logging.access.destination.type: Syslog.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Syslog
          syslog:
            address: 1.2.3.4
            maxLength: 4096
            port: 10514

• Use spec.logging.access.destination.container.maxLength if you are using spec.logging.access.destination.type: Container.

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    replicas: 2
    logging:
      access:
        destination:
          type: Container
          container:
            maxLength: 8192

Prerequisites

• The following assumes that you already created an Ingress Controller.

Procedure

• Update the Ingress Controller to increase the number of threads:

  $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'

  Note

  If you have a node that is capable of running large amounts of resources, you can configure spec.nodePlacement.nodeSelector with labels that match the capacity of the intended node, and configure spec.tuningOptions.threadCount to an appropriately high value.

• You can load balance externally, using the cloud provider load balancer, or internally, using the OpenShift Ingress Controller Load Balancer.
• You can use the single IP address of the load balancer and more familiar ports, such as 8080 and 4200 as shown on the cluster depicted in the graphic.
• Traffic from the external load balancer is directed at the pods, and managed by the load balancer, as depicted in the instance of a down node. See the Kubernetes Services documentation for implementation details.

Prerequisites

• Install the OpenShift CLI (oc).
• Log in as a user with cluster-admin privileges.

Prerequisites

• The following assumes that you already created an Ingress Controller.

Procedure

• Update the Ingress Controller to change the interval between back end health checks:

  $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'

  Note

  To override the healthCheckInterval for a single route, use the route annotation router.openshift.io/haproxy.health.check.interval

Prerequisites

• Install the OpenShift CLI (oc).
• Log in as a user with cluster-admin privileges.

Prerequisites

• Cluster administrator privileges.

Procedure

• Edit the .spec.routeAdmission field of the ingresscontroller resource variable using the following command:

  $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge

  Sample Ingress Controller configuration

  spec:
    routeAdmission:
      namespaceOwnership: InterNamespaceAllowed
  ...

  Tip

  You can alternatively apply the following YAML to configure the route admission policy:

  apiVersion: operator.openshift.io/v1
  kind: IngressController
  metadata:
    name: default
    namespace: openshift-ingress-operator
  spec:
    routeAdmission:
      namespaceOwnership: InterNamespaceAllowed

Prerequisites

• You have installed the OpenShift CLI (oc).
• You have access to an Red Hat OpenShift Service on AWS cluster as a user with the cluster-admin role.

• Configure an external proxy that injects the X-Forwarded-For header into each request before forwarding it to an Ingress Controller.

  To configure the Ingress Controller to pass the header through unmodified, you specify the never policy. The Ingress Controller then never sets the headers, and applications receive only the headers that the external proxy provides.

• Configure the Ingress Controller to pass the X-Forwarded-For header that your external proxy sets on external cluster requests through unmodified.

  To configure the Ingress Controller to set the X-Forwarded-For header on internal cluster requests, which do not go through the external proxy, specify the if-none policy. If an HTTP request already has the header set through the external proxy, then the Ingress Controller preserves it. If the header is absent because the request did not come through the proxy, then the Ingress Controller adds the header.

• Configure an application-specific external proxy that injects the X-Forwarded-For header.

  To configure an Ingress Controller to pass the header through unmodified for an application’s Route, without affecting the policy for other Routes, add an annotation haproxy.router.openshift.io/set-forwarded-headers: if-none or haproxy.router.openshift.io/set-forwarded-headers: never on the Route for the application.

  Note

  You can set the haproxy.router.openshift.io/set-forwarded-headers annotation on a per route basis, independent from the globally set value for the Ingress Controller.

• To enable HTTP/2 on an Ingress Controller, enter the oc annotate command:

  $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

  Replace <ingresscontroller_name> with the name of the Ingress Controller to annotate.

• To enable HTTP/2 for the entire cluster, enter the oc annotate command:

  $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true

  Tip

  You can alternatively apply the following YAML to add the annotation:

  apiVersion: config.openshift.io/v1
  kind: Ingress
  metadata:
    name: cluster
    annotations:
      ingress.operator.openshift.io/default-enable-http2: "true"

Prerequisites

• You created an Ingress Controller.

Prerequisites

• You deployed an Red Hat OpenShift Service on AWS cluster.
• You installed the oc command line interface.

Prerequisites

• You have installed the OpenShift CLI (oc).
• You have access to the cluster as a user with the cluster-admin role.

• Specify an HTTP header to be capitalized by entering the oc patch command.

  1. Enter the oc patch command to change the HTTP host header to Host:

     $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

  2. Annotate the route of the application:

     $ oc annotate routes/my-application haproxy.router.openshift.io/h1-adjust-case=true

     The Ingress Controller then adjusts the host request header as specified.

• Specify adjustments using the HeaderNameCaseAdjustments field by configuring the Ingress Controller YAML file.

  1. The following example Ingress Controller YAML adjusts the host header to Host for HTTP/1 requests to appropriately annotated routes:

     Example Ingress Controller YAML

     apiVersion: operator.openshift.io/v1
     kind: IngressController
     metadata:
       name: default
       namespace: openshift-ingress-operator
     spec:
       httpHeaders:
         headerNameCaseAdjustments:
         - Host

  2. The following example route enables HTTP response header name case adjustments using the haproxy.router.openshift.io/h1-adjust-case annotation:

     Example route YAML

     apiVersion: route.openshift.io/v1
     kind: Route
     metadata:
       annotations:
         haproxy.router.openshift.io/h1-adjust-case: true 1
       name: my-application
       namespace: my-application
     spec:
       to:
         kind: Service
         name: my-application

     1

     Set haproxy.router.openshift.io/h1-adjust-case to true.

Prerequisites

• You configured your firewall to access the default stats port, 1936.

Prerequisites

• The following assumes that you already created an Ingress Controller

Procedure

• Update the Ingress Controller to change the maximum number of connections for HAProxy:

  $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'

  Warning

  If you set the spec.tuningOptions.maxConnections value greater than the current operating system limit, the HAProxy process will not start. See the table in the "Ingress Controller configuration parameters" section for more information about this parameter.

• Multicast packets sent by a pod will be delivered to all other pods in the project, regardless of NetworkPolicy objects. Pods might be able to communicate over multicast even when they cannot communicate over unicast.
• Multicast packets sent by a pod in one project will never be delivered to pods in any other project, even if there are NetworkPolicy objects that allow communication between the projects.

• Multicast packets sent by a pod will be delivered to all other pods in the project.
• Multicast packets sent by a pod in one project will be delivered to pods in other projects only if each project is joined together and multicast is enabled in each joined project.

Prerequisites

• Install the OpenShift CLI (oc).
• You must log in to the cluster with a user that has the cluster-admin or the dedicated-admin role.

Procedure

• Run the following command to enable multicast for a project. Replace <namespace> with the namespace for the project you want to enable multicast for.

  $ oc annotate netnamespace <namespace> \
      netnamespace.network.openshift.io/multicast-enabled=true

Prerequisites

• You have verified that the proxy is accessible from the VPC that the cluster is being installed into. The proxy must also be accessible from the private subnets of the VPC.

Procedure

• Specify a proxy configuration when you create your cluster:

  $ rosa create cluster \
   <other_arguments_here> \
   --additional-trust-bundle-file <path_to_ca_bundle_file> \ 1 2 3
   --http-proxy http://<username>:<password>@<ip>:<port> \ 4 5
   --https-proxy https://<username>:<password>@<ip>:<port> \ 6 7
   --no-proxy example.com 8

  1 4 6

  The additional-trust-bundle-file, http-proxy, and https-proxy arguments are all optional.

  2

  If you use the additional-trust-bundle-file argument without an http-proxy or https-proxy argument, the trust bundle is added to the trust store and used to verify cluster system egress traffic. In that scenario, the bundle is not configured to be used with a proxy.

  3

  The additional-trust-bundle-file argument is a file path pointing to a bundle of PEM-encoded X.509 certificates, which are all concatenated together. The additionalTrustBundle parameter is required unless the identity certificate of the proxy is signed by an authority from the RHCOS trust bundle. If you use an MITM transparent proxy network that does not require additional proxy configuration but requires additional CAs, you must provide the MITM CA certificate.

  5 7

  The http-proxy and https-proxy arguments must point to a valid URL.

  8

  A comma-separated list of destination domain names, IP addresses, or network CIDRs to exclude proxying.

  Preface a domain with . to match subdomains only. For example, .y.com matches x.y.com, but not y.com. Use * to bypass proxy for all destinations. If you scale up workers that are not included in the network defined by the networking.machineNetwork[].cidr field from the installation configuration, you must add them to this list to prevent connection issues.

  This field is ignored if neither the httpProxy or httpsProxy fields are set.

Prerequisites

• You have an Red Hat OpenShift Service on AWS cluster .
• Your cluster is deployed in a VPC.

Verification

• Under the Virtual Private Cloud (VPC) section on the Networking page, verify that the proxy configuration for your cluster is as expected.

Prerequisites

• You have installed and configured the latest ROSA (rosa) and OpenShift (oc) CLIs on your installation host.
• You have a ROSA cluster that is deployed in a VPC.

Procedure

• Edit the cluster configuration to add or update the cluster-wide proxy details:

  $ rosa edit cluster \
   --cluster $CLUSTER_NAME \
   --additional-trust-bundle-file <path_to_ca_bundle_file> \ 1 2 3
   --http-proxy http://<username>:<password>@<ip>:<port> \ 4 5
   --https-proxy https://<username>:<password>@<ip>:<port> \ 6 7
    --no-proxy example.com 8

  1 4 6

  The additional-trust-bundle-file, http-proxy, and https-proxy arguments are all optional.

  2

  If you use the additional-trust-bundle-file argument without an http-proxy or https-proxy argument, the trust bundle is added to the trust store and used to verify cluster system egress traffic. In that scenario, the bundle is not configured to be used with a proxy.

  3

  The additional-trust-bundle-file argument is a file path pointing to a bundle of PEM-encoded X.509 certificates, which are all concatenated together. The additionalTrustBundle parameter is required unless the identity certificate of the proxy is signed by an authority from the RHCOS trust bundle. If you use an MITM transparent proxy network that does not require additional proxy configuration but requires additional CAs, you must provide the MITM CA certificate.

  Note

  You should not attempt to change the proxy or additional trust bundle configuration on the cluster directly. These changes must be applied by using the ROSA CLI (rosa) or Red Hat OpenShift Cluster Manager. Any changes that are made directly to the cluster will be reverted automatically.

  5 7

  The http-proxy and https-proxy arguments must point to a valid URL.

  8

  A comma-separated list of destination domain names, IP addresses, or network CIDRs to exclude proxying.

  Preface a domain with . to match subdomains only. For example, .y.com matches x.y.com, but not y.com. Use * to bypass proxy for all destinations. If you scale up workers that are not included in the network defined by the networking.machineNetwork[].cidr field from the installation configuration, you must add them to this list to prevent connection issues.

  This field is ignored if neither the httpProxy or httpsProxy fields are set.

Prerequisites

• You must have cluster administrator privileges.
• You have installed the ROSA CLI (rosa).

Procedure

• Use the rosa edit command to modify the proxy. You must pass empty strings to the --http-proxy and --https-proxy arguments to clear the proxy from the cluster:

  $ rosa edit cluster -c <cluster_name> --http-proxy "" --https-proxy ""

  Note

  While your proxy might only use one of the proxy arguments, the empty fields are ignored, so passing empty strings to both the --http-proxy and --https-proxy arguments do not cause any issues.

  Example Output

  I: Updated cluster <cluster_name>

Verification

• You can verify that the proxy has been removed from the cluster by using the rosa describe command:

  $ rosa describe cluster -c <cluster_name>

  Before removal, the proxy IP displays in a proxy section:

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>
  Additional trust bundle:    REDACTED

  After removing the proxy, the proxy section is removed:

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Additional trust bundle:    REDACTED

Prerequisites

• You must have cluster administrator privileges.
• You have installed the ROSA CLI (rosa).
• Your cluster has certificate authorities added.

Procedure

• Use the rosa edit command to modify the CA trust bundle. You must pass empty strings to the --additional-trust-bundle-file argument to clear the trust bundle from the cluster:

  $ rosa edit cluster -c <cluster_name> --additional-trust-bundle-file ""

  Example Output

  I: Updated cluster <cluster_name>

Verification

• You can verify that the trust bundle has been removed from the cluster by using the rosa describe command:

  $ rosa describe cluster -c <cluster_name>

  Before removal, the Additional trust bundle section appears, redacting its value for security purposes:

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>
  Additional trust bundle:    REDACTED

  After removing the proxy, the Additional trust bundle section is removed:

  Name:                       <cluster_name>
  ID:                         <cluster_internal_id>
  External ID:                <cluster_external_id>
  OpenShift Version:          4.0
  Channel Group:              stable
  DNS:                        <dns>
  AWS Account:                <aws_account_id>
  API URL:                    <api_url>
  Console URL:                <console_url>
  Region:                     us-east-1
  Multi-AZ:                   false
  Nodes:
   - Control plane:           3
   - Infra:                   2
   - Compute:                 2
  Network:
   - Type:                    OVNKubernetes
   - Service CIDR:            <service_cidr>
   - Machine CIDR:            <machine_cidr>
   - Pod CIDR:                <pod_cidr>
   - Host Prefix:             <host_prefix>
  Proxy:
   - HTTPProxy:               <proxy_url>

• Deny all traffic:

  To make a project deny by default, add a NetworkPolicy object that matches all pods but accepts no traffic:

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: deny-by-default
  spec:
    podSelector: {}
    ingress: []

• Only allow connections from the Red Hat OpenShift Service on AWS Ingress Controller:

  To make a project allow only connections from the Red Hat OpenShift Service on AWS Ingress Controller, add the following NetworkPolicy object.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-from-openshift-ingress
  spec:
    ingress:
    - from:
      - namespaceSelector:
          matchLabels:
            network.openshift.io/policy-group: ingress
    podSelector: {}
    policyTypes:
    - Ingress

• Only accept connections from pods within a project:

  To make pods accept connections from other pods in the same project, but reject all other connections from pods in other projects, add the following NetworkPolicy object:

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-same-namespace
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector: {}

• Only allow HTTP and HTTPS traffic based on pod labels:

  To enable only HTTP and HTTPS access to the pods with a specific label (role=frontend in following example), add a NetworkPolicy object similar to the following:

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-http-and-https
  spec:
    podSelector:
      matchLabels:
        role: frontend
    ingress:
    - ports:
      - protocol: TCP
        port: 80
      - protocol: TCP
        port: 443

• Accept connections by using both namespace and pod selectors:

  To match network traffic by combining namespace and pod selectors, you can use a NetworkPolicy object similar to the following:

  kind: NetworkPolicy
  apiVersion: networking.k8s.io/v1
  metadata:
    name: allow-pod-and-namespace-both
  spec:
    podSelector:
      matchLabels:
        name: test-pods
    ingress:
      - from:
        - namespaceSelector:
            matchLabels:
              project: project_name
          podSelector:
            matchLabels:
              name: test-pods

• Reduce the number of OVS flow rules by using namespaces to contain groups of pods that need to be isolated.

  NetworkPolicy objects that select a whole namespace, by using the namespaceSelector or an empty podSelector, generate only a single OVS flow rule that matches the VXLAN virtual network ID (VNID) of the namespace.

• Keep the pods that do not need to be isolated in their original namespace, and move the pods that require isolation into one or more different namespaces.
• Create additional targeted cross-namespace network policies to allow the specific traffic that you do want to allow from the isolated pods.

• For network policies with the same spec.podSelector spec, it is more efficient to use one network policy with multiple ingress or egress rules, than multiple network policies with subsets of ingress or egress rules.

• Every ingress or egress rule based on the podSelector or namespaceSelector spec generates the number of OVS flows proportional to number of pods selected by network policy + number of pods selected by ingress or egress rule. Therefore, it is preferable to use the podSelector or namespaceSelector spec that can select as many pods as you need in one rule, instead of creating individual rules for every pod.

  For example, the following policy contains two rules:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: test-network-policy
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend
    - from:
      - podSelector:
          matchLabels:
            role: backend

  The following policy expresses those same two rules as one:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: test-network-policy
  spec:
    podSelector: {}
    ingress:
    - from:
      - podSelector:
          matchExpressions:
          - {key: role, operator: In, values: [frontend, backend]}

  The same guideline applies to the spec.podSelector spec. If you have the same ingress or egress rules for different network policies, it might be more efficient to create one network policy with a common spec.podSelector spec. For example, the following two policies have different rules:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: policy1
  spec:
    podSelector:
      matchLabels:
        role: db
    ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend
  ---
  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: policy2
  spec:
    podSelector:
      matchLabels:
        role: client
    ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend

  The following network policy expresses those same two rules as one:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: policy3
  spec:
    podSelector:
      matchExpressions:
      - {key: role, operator: In, values: [db, client]}
    ingress:
    - from:
      - podSelector:
          matchLabels:
            role: frontend

  You can apply this optimization when only multiple selectors are expressed as one. In cases where selectors are based on different labels, it may not be possible to apply this optimization. In those cases, consider applying some new labels for network policy optimization specifically.

• Creating a network policy

Prerequisites

• You logged in to OpenShift Cluster Manager.
• You created an Red Hat OpenShift Service on AWS cluster.
• You configured an identity provider for your cluster.
• You added your user account to the configured identity provider.
• You created a project within your Red Hat OpenShift Service on AWS cluster.

Prerequisites

• You logged in to OpenShift Cluster Manager.
• You created an Red Hat OpenShift Service on AWS cluster.
• You configured an identity provider for your cluster.
• You added your user account to the configured identity provider.
• You created a network policy.

Prerequisites

• You logged in to OpenShift Cluster Manager.
• You created an Red Hat OpenShift Service on AWS cluster.
• You configured an identity provider for your cluster.
• You added your user account to the configured identity provider.

Prerequisites

• Your cluster uses a network plugin that supports NetworkPolicy objects, such as the OVN-Kubernetes network plugin or the OpenShift SDN network plugin with mode: NetworkPolicy set. This mode is the default for OpenShift SDN. This mode is the default for OpenShift SDN.
• You installed the OpenShift CLI (oc).
• You are logged in to the cluster with a user with admin privileges.

Prerequisites

• Install the ROSA CLI (rosa).
• Log in to the cluster as a cluster administrator.

Procedure

• To label a node so that it can host one or more egress IP addresses, enter the following command:

  $ rosa edit machinepool <machinepool_name> --cluster=<cluster_name> --labels "k8s.ovn.org/egress-assignable="

  Important

  This command replaces any exciting node labels on your machinepool. You should include any of the desired labels to the --labels field to ensure that your existing node labels persist.

• Assigning egress IPs

Prerequisites

• You installed the OpenShift CLI (oc).
• You are logged in as an administrator.
• You have a web application that exposes a port and a TCP endpoint listening for traffic on the port.

Verification

• To verify that the route resource that you created, run the following command:

  $ oc get routes -o yaml <name of resource> 1

  1

  In this example, the route is named hello-openshift.

Prerequisites

• You need a deployed Ingress Controller on a running cluster.

• Enable HSTS per-route
• Disable HSTS per-route
• Enforce HSTS per-domain, for a set of domains, or use namespace labels in combination with domains

Prerequisites

• You have installed the OpenShift CLI (oc).
• You are logged into an Red Hat OpenShift Service on AWS cluster as a project administrator.
• You have a web application that exposes a port and an HTTP or TLS endpoint listening for traffic on the port.

Prerequisites

• You have a service that you want to expose.
• You have access to the OpenShift CLI (oc).

Verification

• Verify that Red Hat OpenShift Service on AWS has created the expected route for the Ingress object by running the following command:

  $ oc get routes -o yaml

  Example output

  apiVersion: v1
  items:
  - apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: frontend-j9sdd 1
      ...
    spec:
    ...
      tls: 2
        insecureEdgeTerminationPolicy: Redirect
        termination: edge 3
    ...

  1

  The name of the route includes the name of the Ingress object followed by a random suffix.

  2

  In order to use the default certificate, the route should not specify spec.certificate.

  3

  The route should specify the edge termination policy.

Prerequisites

• You may have a certificate/key pair in PEM-encoded files, where the certificate is valid for the route host.
• You may have a separate CA certificate in a PEM-encoded file that completes the certificate chain.
• You must have a separate destination CA certificate in a PEM-encoded file.
• You must have a service that you want to expose.

Prerequisites

• You must have a certificate/key pair in PEM-encoded files, where the certificate is valid for the route host.
• You may have a separate CA certificate in a PEM-encoded file that completes the certificate chain.
• You must have a separate destination CA certificate in a PEM-encoded file.
• You must have a service that you want to expose.

• Create a secure Route resource using reencrypt TLS termination and a custom certificate:

  $ oc create route reencrypt --service=frontend --cert=tls.crt --key=tls.key --dest-ca-cert=destca.crt --ca-cert=ca.crt --hostname=www.example.com

  If you examine the resulting Route resource, it should look similar to the following:

  YAML Definition of the Secure Route

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend
  spec:
    host: www.example.com
    to:
      kind: Service
      name: frontend
    tls:
      termination: reencrypt
      key: |-
        -----BEGIN PRIVATE KEY-----
        [...]
        -----END PRIVATE KEY-----
      certificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      caCertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      destinationCACertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

  See oc create route reencrypt --help for more options.

Prerequisites

• You must have a certificate/key pair in PEM-encoded files, where the certificate is valid for the route host.
• You may have a separate CA certificate in a PEM-encoded file that completes the certificate chain.
• You must have a service that you want to expose.

• Create a secure Route resource using edge TLS termination and a custom certificate.

  $ oc create route edge --service=frontend --cert=tls.crt --key=tls.key --ca-cert=ca.crt --hostname=www.example.com

  If you examine the resulting Route resource, it should look similar to the following:

  YAML Definition of the Secure Route

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: frontend
  spec:
    host: www.example.com
    to:
      kind: Service
      name: frontend
    tls:
      termination: edge
      key: |-
        -----BEGIN PRIVATE KEY-----
        [...]
        -----END PRIVATE KEY-----
      certificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----
      caCertificate: |-
        -----BEGIN CERTIFICATE-----
        [...]
        -----END CERTIFICATE-----

  See oc create route edge --help for more options.

Prerequisites

• You must have a service that you want to expose.

Procedure

• Create a Route resource:

  $ oc create route passthrough route-passthrough-secured --service=frontend --port=8080

  If you examine the resulting Route resource, it should look similar to the following:

  A Secured Route Using Passthrough Termination

  apiVersion: route.openshift.io/v1
  kind: Route
  metadata:
    name: route-passthrough-secured 1
  spec:
    host: www.example.com
    port:
      targetPort: 8080
    tls:
      termination: passthrough 2
      insecureEdgeTerminationPolicy: None 3
    to:
      kind: Service
      name: frontend

  1

  The name of the object, which is limited to 63 characters.

  2

  The termination field is set to passthrough. This is the only required tls field.

  3

  Optional insecureEdgeTerminationPolicy. The only valid values are None, Redirect, or empty for disabled.

  The destination pod is responsible for serving certificates for the traffic at the endpoint. This is currently the only method that can support requiring client certificates, also known as two-way authentication.