Configuring and deploying Gateway policies with Connectivity Link

Procedure

1. If your Gateway namespace does not already exist, create it as follows:

   kubectl create ns ${gatewayNS}

2. If the secret for your DNS provider credentials was not already created when installing Connectivity Link, create this secret in your Gateway namespace as follows:

   kubectl -n ${gatewayNS} create secret generic aws-credentials \
     --type=kuadrant.io/aws \
     --from-literal=AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
     --from-literal=AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

3. Before adding a TLS issuer, you must also create the credentials secret in the cert-manager namespace as follows:

   kubectl -n cert-manager create secret generic aws-credentials \
     --type=kuadrant.io/aws \
     --from-literal=AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID \
     --from-literal=AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY

Procedure

1. Enter the following command to define a TLS issuer. This example uses Let’s Encrypt, which you must also apply to all clusters:

   kubectl apply -f - <<EOF
   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: ${clusterIssuerName}
   spec:
     acme:
       email: ${EMAIL}
       privateKeySecretRef:
         name: le-secret
       server: https://acme-v02.api.letsencrypt.org/directory
       solvers:
         - dns01:
             route53:
               hostedZoneID: ${zid}
               region: ${AWS_REGION}
               accessKeyIDSecretRef:
                 key: AWS_ACCESS_KEY_ID
                 name: aws-credentials
               secretAccessKeySecretRef:
                 key: AWS_SECRET_ACCESS_KEY
                 name: aws-credentials
   EOF

2. Wait for the ClusterIssuer to become ready as follows:

   kubectl wait clusterissuer/${clusterIssuerName} --for=condition=ready=true

Procedure

1. Enter the following command to create the Gateway:

   kubectl apply -f - <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: Gateway
   metadata:
     name: ${gatewayName}
     namespace: ${gatewayNS}
     labels:
       kuadrant.io/gateway: "true"
   spec:
       gatewayClassName: istio
       listeners:
       - allowedRoutes:
           namespaces:
             from: Same
         hostname: "*.${rootDomain}"
         name: api
         port: 443
         protocol: HTTPS
         tls:
           certificateRefs:
           - group: ""
             kind: Secret
             name: api-${gatewayName}-tls
           mode: Terminate
   EOF

2. Check the status of your Gateway as follows:

   kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}'
   kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.conditions[?(@.type=="Programmed")].message}'

   Your Gateway should be accepted and programmed, which means valid and assigned an external address.

3. However, if you check your HTTPS listener status as follows, you will see that it is not yet programmed or ready to accept traffic due to bad TLS configuration:

   kubectl get gateway ${gatewayName} -n ${gatewayNS} -o=jsonpath='{.status.listeners[0].conditions[?(@.type=="Programmed")].message}'

   Connectivity Link can help with this by using a TLSPolicy, which is described in the next step.

Procedure

1. To distribute this Gateway across multiple clusters, repeat this setup process for each cluster.

   By default, this will implement a round-robin DNS strategy to distribute traffic evenly across the different clusters. Setting up your Gateways to serve clients based on their geographic location is straightforward with your current configuration.

2. Assuming that you have deployed Gateway instances across multiple clusters as per this guide, the next step involves updating the DNS controller with the geographic regions of the visible Gateways.

   For instance, if you have one cluster in North America and another in the EU, you can direct traffic to these Gateways based on their location by configuring the appropriate policy. For your North American cluster, you can create a DNSPolicy and set the loadBalancing:geo field to US.

Procedure

1. Create the namespace for your application as follows, if it does not already exist:

   kubectl create ns ${devNS}

2. Deploy the toystore application to your developer namespace as follows, if it has not already been deployed:

   kubectl apply -f https://raw.githubusercontent.com/Kuadrant/Kuadrant-operator/main/examples/toystore/toystore.yaml -n ${devNS}

Procedure

1. Enter the following command to define an HTTP route for your Toystore application API:

   kubectl apply -f - <<EOF
   apiVersion: gateway.networking.k8s.io/v1
   kind: HTTPRoute
   metadata:
     name: toystore
     labels:
       deployment: toystore
       service: toystore
   spec:
     parentRefs:
     - name: ${gatewayName}
       namespace: ${gatewayNS}
     hostnames:
     - "api.${rootDomain}"
     rules:
     - matches:
       - method: GET
         path:
           type: PathPrefix
           value: "/cars"
       - method: GET
         path:
           type: PathPrefix
           value: "/dolls"
       backendRefs:
       - name: toystore
         port: 80
     - matches:
       - path:
           type: PathPrefix
           value: "/admin"
       backendRefs:
       - name: toystore
         port: 80
   EOF

   With this HTTPRoute in place, the service that you deployed is now exposed by the Gateway.

2. You can access your API endpoint over HTTPS as follows:

   export INGRESS_HOST=$(kubectl get gtw ${gatewayName} -o jsonpath='{.status.addresses[0].value}' -n api-gateway)
   
   curl --resolve api.${rootDomain}:443:${INGRESS_HOST} "https://api.${rootDomain}/cars"

Procedure

1. Define API keys for bob and alice users as follows:

   kubectl apply -f - <<EOF
   apiVersion: v1
   kind: Secret
   metadata:
     name: bob-key
     labels:
       authorino.kuadrant.io/managed-by: authorino
       app: toystore
     annotations:
       secret.kuadrant.io/user-id: bob
   stringData:
     api_key: IAMBOB
   type: Opaque
   ---
   apiVersion: v1
   kind: Secret
   metadata:
     name: alice-key
     labels:
       authorino.kuadrant.io/managed-by: authorino
       app: toystore
     annotations:
       secret.kuadrant.io/user-id: alice
   stringData:
     api_key: IAMALICE
   type: Opaque
   EOF

2. Override the AuthPolicy to start accepting the API keys as follows:

   kubectl apply -f - <<EOF
   apiVersion: kuadrant.io/v1
   kind: AuthPolicy
   metadata:
     name: toystore
   spec:
     targetRef:
       group: gateway.networking.k8s.io
       kind: HTTPRoute
       name: toystore
     rules:
       authentication:
         "api-key-users":
           apiKey:
             selector:
               matchLabels:
                 app: toystore
           credentials:
             authorizationHeader:
               prefix: APIKEY
       response:
         success:
           filters:
             "identity":
               json:
                 properties:
                   "userid":
                     selector: auth.identity.metadata.annotations.secret\.kuadrant\.io/user-id
   EOF

Procedure

1. Enter the following command to set rate limits for specific users:

   kubectl apply -f - <<EOF
   apiVersion: kuadrant.io/v1
   kind: RateLimitPolicy
   metadata:
     name: toystore
   spec:
     targetRef:
       group: gateway.networking.k8s.io
       kind: HTTPRoute
       name: toystore
     limits:
       "general-user":
         rates:
         - limit: 1
           duration: 3
           unit: second
         counters:
         - metadata.filter_metadata.envoy\.filters\.http\.ext_authz.identity.userid
         when:
         - selector: metadata.filter_metadata.envoy\.filters\.http\.ext_authz.identity.userid
           operator: neq
           value: bob
       "bob-limit":
         rates:
         - limit: 2
           duration: 3
           unit: second
         when:
         - selector: metadata.filter_metadata.envoy\.filters\.http\.ext_authz.identity.userid
           operator: eq
           value: bob
   EOF

   Note

   It might take a few minutes for the RateLimitPolicy to be applied, depending on your cluster.

   As another example, you could give bob twice as many requests to use compared to all other users.

2. To test your new setup, send requests as alice as follows:

   while :; do curl --resolve api.${rootDomain}:443:${INGRESS_HOST} --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMALICE' "https://api.${rootDomain}/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done

3. Send requests as bob as follows:

   while :; do curl --resolve api.${rootDomain}:443:${INGRESS_HOST} --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMBOB' "https://api.${rootDomain}/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done

   Note

   If you set up a DNS provider and configured a DNSPolicy as described in the platform engineer workflow, you can omit the --resolve api.${rootDomain}:443:${INGRESS_HOST} flag. For example, for alice as follows:

   while :; do curl --write-out '%{http_code}\n' --silent --output /dev/null -H 'Authorization: APIKEY IAMALICE' "https://api.${rootDomain}/cars" | grep -E --color "\b(429)\b|$"; sleep 1; done

   Note

   If you followed through this guide on more than one cluster, the DNS record for the HTTPRoute hostname will have multiple IP addresses. This means that requests will be made in a round-robin pattern across clusters because your DNS provider sends different responses to lookups.