Untitled :: Safeguarding Application Connectivity for the Hybrid Cloud

Activity: Platform Engineer Workflow

Module 3

To perform the section of the workshop, ensure you are logged into OpenShift within the terminal.

In the right-upper terminal, running the following command should display admin
```
oc whoami
```

If this is not the case, run the following command to log in to OpenShift.

oc login -u admin -p {ocp_cluster_openshift_cluster_admin_password} https://172.30.0.1:443

Workshop set up

To ensure the module can be completed within a short timeframe, some of the components and policies have been preconfigured.

An AWS Hosted Zone (DNS domain) travels.{ocp_cluster_workshop_main_domain} has been created on AWS Route 53.
A Gateway resource prod-web referencing the DNS domain travels.{ocp_cluster_workshop_main_domain}
Red Hat Connectivity Link operator and a few policies (to provide DNS management in AWS DNS provider) are pre-configured.
A sample partner web-portal to test secure external access of the travel-agency core services has been deployed

Explore Red Hat Connectivity Link set up

Navigate to {ocp_cluster_openshift_cluster_console_url}/kuadrant/overview[Connectivity Link Overview^, window='console'], and log in with username admin and password {ocp_cluster_openshift_cluster_admin_password} if prompted.

In the Overview section, you will notice that a Gateway, Policies (TLSPolicy and DNSPolicy), and an echo-api HTTPRoute have been pre-configured.

The Status columns for all the resources should display as Enforced in green. However, you may occasionally face some errors where the Status shows an error, similar to the screenshot below.

To resolve this, run the following command from the OpenShift Terminal (upper terminal) to restart the Kuadrant pods to ensure all the resources return to a healthy state.

oc login -u admin -p <pwd> https://172.30.0.1:443
oc delete pods --all -n kuadrant-system

Review the Gateway

A Gateway resource defines how external traffic enters a cluster and references a DNS domain (hosted zone).

Access the prod-web Gateway shown under the Gateways section.

Here is a snippet of the Gateway details. Optionally, you could also navigate to the {ocp_cluster_openshift_cluster_console_url}/k8s/ns/ingress-gateway/gateway.networking.k8s.io%7Ev1%7EGateway/prod-web/yaml[YAML tab^, window=console] on the console to review it.

spec:
  gatewayClassName: istio
  listeners:
    - allowedRoutes:
        namespaces:
          from: All
      hostname: '*.travels.{ocp_cluster_workshop_main_domain}' (1)
      name: api
      port: 443
      protocol: HTTPS
      tls:
        certificateRefs: (2)
          - group: ''
            kind: Secret
            name: api-tls
        mode: Terminate

1	This is the wildcarded hostname which will handle all traffic routed through the `travels.{ocp_cluster_workshop_main_domain}` domain
2	A TLS Policy has been pre-created; it leverages a TLS-issuer to manage TLS certificates for the listeners defined within the Gateway.

Review the DNSPolicy

A DNS Policy is attached to a Gateway to enable DNS management by managing DNS records in external DNS providers - in this case, AWS Route53. This policy has been pre-created, because DNS resolution for new DNS records may take time to propagate and could delay your progress in this module.

Here is a snippet of the DNS Policy details

spec:
  targetRef:
    name: prod-web  (1)
    group: gateway.networking.k8s.io
    kind: Gateway
  providerRefs:
  - name: prod-web-aws-credentials  (2)

Gateway resource to which this policy is applied

DNS Provider credentials to be able to create DNS records

DNS Policies can be created with more complex configurations especially for hybrid cloud architectures, including default Geo Code and load balancing options. This allows traffic routing across a hybrid cloud architecture using repeatable Policy APIs configuration with a GitOps approach.

Optionally, you could also navigate to the {ocp_cluster_openshift_cluster_console_url}/k8s/ns/ingress-gateway/kuadrant.io%7Ev1%7EDNSPolicy/prod-web-dnspolicy/yaml[prod-web-dnspolicy, window="console"] from the console.

Access the `echo-api` HTTPRoute

HTTPRoutes are attached to a Gateway to route all incoming traffic to appropriate backend services.

The echo-api HTTPRoute has been deployed as a way for Platform Engineers to verify their setup before opening this up to developers.

Execute the following curl command in the upper terminal to access the echo-api

curl -k -w "%{http_code}" https://echo.travels.{ocp_cluster_workshop_main_domain} && echo

You will observe that this endpoint is accessible without any authentication parameters, and returns an HTTP 200 successful response status code.

{
  "method": "GET",
  ....
  "body": "",
  "headers": {
    "HTTP_HOST": "echo.travels.sandbox4962.opentlc.com",
    "HTTP_USER_AGENT": "curl/7.76.1",
    ....
    "HTTP_VERSION": "HTTP/1.1"
  },
  "uuid": "5dc42712-53c3-4f3d-94ec-9d96a501b213"
}200

This is not the intended behavior and needs to be addressed. In the next step, you will create an AuthPolicy to secure this endpoint.

Create a zero-trust AuthPolicy

As a Platform Engineer, you will now set up a zero-trust AuthPolicy to secure all incoming traffic.

Zero trust a security model where every interaction begins in an untrusted state

Click the (+) button on the top navigation bar of {ocp_cluster_openshift_cluster_console_url}[OpenShift Console^, window="console"] to create a new resource.

In the YAML editor, copy the following AuthPolicy CR.

apiVersion: kuadrant.io/v1
kind: AuthPolicy
metadata:
  name: prod-web-deny-all
  namespace: ingress-gateway
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: prod-web
  rules:
    authorization:
      deny-all:
        opa:
          rego: "allow = false"
    response:
      unauthorized:
        headers:
          "content-type":
            value: application/json
        body:
          value: |
            {
              "error": "Forbidden",
              "message": "Access denied by default by the gateway operator. If you are the administrator of the service, create a specific auth policy for the route."
            }

This policy denies all incoming requests and sends a custom error message as part of the response.
Click the Create button at the bottom of the YAML editor
Scroll to the bottom of the AuthPolicy details page to note that the policy has been accepted and enforced
Test the echo-api HTTPRoute to test the setup so far, to ensure all requests are denied due to the zero trust policy you have set up. Execute the following curl command on the upper Terminal to access the echo-api
```
curl -k -w "%{http_code}" https://echo.travels.{ocp_cluster_workshop_main_domain} && echo
```

This should now display an error message instead of success. Note that this is the same error message as configured in the Gateway.

{
  "error": "Forbidden",
  "message": "Access denied by default by the gateway operator. If you are the administrator of the service, create a specific auth policy for the route."
}
403

This error message is caused by the zero-trust AuthPolicy applied to the Gateway to which the API HTTPRoute is attached. Since no other AuthPolicy is attached to echo-api, the Gateway’s AuthPolicy is enforced on it.

There is a possibility that you may face such an error: curl: (6) Could not resolve host: echo.travels.sandbo123.opentlc.com. This may occur because DNS resolution can take a few minutes. Please try again in a minute or two.

Create a default low-limit RateLimitPolicy

RateLimitPolicy provides rate limiting of requests to Gateways and HTTPRoutes and also offers fine-grained matching rules to apply the limits to.

Click the (+) button on the top navigation bar of {ocp_cluster_openshift_cluster_console_url}[OpenShift Console^, window="console"] to create a new resource.

In the YAML editor, copy the following RateLimitPolicy CR and click the Create button.

apiVersion: kuadrant.io/v1
kind: RateLimitPolicy
metadata:
  name: ingress-gateway-rlp-lowlimits
  namespace: ingress-gateway
spec:
  targetRef:
    group: gateway.networking.k8s.io
    kind: Gateway
    name: prod-web
  limits:
    "default-limits":
      rates:
      - limit: 5
        window: 10s

Scroll to the bottom of the RateLimitPolicy details page to note that the RateLimitPolicy has been accepted and enforced.
Optionally, execute the following curl command on the upper Terminal to access the echo-api and check if the default rate limit has been applied.
```
for i in {1..10}; do echo "($i)"; curl -k -w "%{http_code}" https://echo.travels.{ocp_cluster_workshop_main_domain}; echo; done
```
You should see the Too Many Requests - 429 message after the fifth call
Navigate to Red Hat Connectivity Link’s {ocp_cluster_openshift_cluster_console_url}/kuadrant/policy-topology[Policy Topology^, window="console"].
Note that the Auth, DNS, Rate Limit, and TLS policies are all attached to the prod-web Gateway, and are inherited by the echo-api HTTRoute.
Navigate to {ocp_cluster_openshift_cluster_console_url}/kuadrant/overview[Connectivity Link Overview^, window='console'] to view the updated Gateway Traffic Analysis showing stats around requests and errors.

Summary

You explored the Platform Engineer’s workflow, setting up the Gateway, TLS Policy, DNS Policy, and Auth Policy.
You validated the echo-api HTTPRoute and confirmed access was denied as expected.
Next, you’ll follow the App Developer’s workflow to expose a Travels Service route and apply specific policies to allow secure access to the core services endpoints

Activity: Platform Engineer Workflow

Workshop set up

Explore Red Hat Connectivity Link set up

Review the Gateway

Review the DNSPolicy

Access the echo-api HTTPRoute

Create a zero-trust AuthPolicy

Create a default low-limit RateLimitPolicy

Summary

Access the `echo-api` HTTPRoute