Chapter 2. Connect and secure APIs and services


After you install and deploy Connectivity Link, you can configure access and security for your APIs, services, and applications.

2.1. Application development workflow

You can use Connectivity Link to protect applications and APIs on existing OpenShift Container Platform clusters and Gateway objects. You can also monitor workloads and the status of OpenShift Container Platform resource metrics and tracing by using observability dashboards and alerts.

Example tasks
  • Configure routes

    • Set up application routes and API definitions and publish them to the cluster.
  • Protect applications with Auth policies and allow API access

    • OAuth 2
    • JWT authorization policies
    • API keys
    • Kubernetes tokens
    • Role-based access (RBAC)
    • Relationship-based access control (ReBAC)
    • Open Policy Agent (OPA)
  • Observe application and API performance

    • Monitor workloads and the status of OpenShift Container Platform resource metrics and tracing by using observability dashboards and alerts.
    • Ensure that APIs meet performance and availability benchmarks achieved by other data centers by viewing API metrics, such as uptime, requests per second, latency, and errors per minute.

2.2. Allow API access

You can allow users access to your APIs by overriding existing deny-all gateway-level policies. You must also attach application-level AuthPolicy objects and rate-limiting CRs to your HTTPRoute objects.

Important

The following example allows two users access to the Toystore API by using API keys to authenticate the requests. Other options, such as OpenID Connect, are more appropriate for production use. Use the "least-access" approach that is best for your use case.

Prerequisites

  • Connectivity Link is installed.
  • You configured Connectivity Link policies.
  • You installed the OpenShift CLI (oc).
  • You are logged into OpenShift Container Platform as a cluster administrator.

Procedure

  1. Set the KUADRANT_SYSTEM_NS environment variable based on where you created the Kuadrant custom resource (CR) by running the following command:

    $ export KUADRANT_SYSTEM_NS=$(oc get kuadrant -A -o jsonpath="{.items[0].metadata.namespace}")
  2. Create the Secret custom resources (CRs), or API keys, for bob and alice users that contain the following information:

    Example user Secret CRs

    apiVersion: v1
    kind: Secret
    metadata:
      name: bob-key
      namespace: ${KUADRANT_SYSTEM_NS}
      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
      namespace: ${KUADRANT_SYSTEM_NS}
      labels:
        authorino.kuadrant.io/managed-by: authorino
        app: toystore
      annotations:
        secret.kuadrant.io/user-id: alice
    stringData:
      api_key: IAMALICE
    type: Opaque
    EOF

  3. Apply the API keys by running the following commands:

    $ oc apply -f <bob_key.yaml>

    Replace <bob_key.yaml> with the filename you used.

    $ oc apply -f <alice_key.yaml>

    Replace <alice_key.yaml> with the filename you used.

  4. Create a new AuthPolicy in a different namespace that overrides the deny-all policy and accepts the API keys. For example, the following toystore-auth.yaml:

    Example user AuthPolicy

    apiVersion: kuadrant.io/v1
    kind: AuthPolicy
    metadata:
      name: toystore-auth
      namespace: ${KUADRANT_DEVELOPER_NS}
    spec:
      targetRef:
        group: gateway.networking.k8s.io
        kind: HTTPRoute
        name: toystore
      defaults:
       when:
         - predicate: "request.path != '/health'"
       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

  5. Apply the AuthPolicy CR by running the following commands:

    $ oc apply -f <bob_key.yaml>

    Replace <bob_key.yaml> with the filename you used.

2.2.1. About Service and Deployment objects

Before you can create a route to host your application at a public URL, you must create a Service custom resource (CR) as a routing rule. As a best practice, you must also create a Deployment object that is the application pod.

The following is an example of both Deployment and Service CRs for the Toystore example application that you can use as reference in creating your own.

Example application Deployment and Service CRs

apiVersion: apps/v1
kind: Deployment
metadata:
  name: toystore
  labels:
    app: toystore
spec:
  selector:
    matchLabels:
      app: toystore
  template:
    metadata:
      labels:
        app: toystore
    spec:
      containers:
        - name: toystore
          image: quay.io/kuadrant/authorino-examples:api
          env:
            - name: LOG_LEVEL
              value: "debug"
            - name: PORT
              value: "3000"
          ports:
            - containerPort: 3000
              name: http
  replicas: 1
---
apiVersion: v1
kind: Service
metadata:
  name: toystore
spec:
  selector:
    app: toystore
  ports:
    - name: http
      port: 80
      protocol: TCP
      targetPort: 3000

2.2.2. Create an HTTP route for an application

As an application developer, you can create a route to host your application at a public URL. In Gateway API, use the HTTPRoute custom resource (CR) to specify the routing behavior of HTTP requests from your Gateway object to your application. An HTTPRoute CR is especially useful for multiplexing HTTP or terminated HTTPS connections.

Prerequisites

  • You installed Connectivity Link on one or more clusters.
  • You installed the OpenShift CLI (oc).
  • You have write access to the OpenShift Container Platform namespaces you need to work with.
  • You have access to external or on-premise DNS.
  • You created and applied a Gateway object.
  • You have a web application that exposes a port and a TCP endpoint listening for traffic on the port.
  • You created a Service object for your application.
  • You have a local Certificate Authority (CA) bundle.

Procedure

  1. Create an HTTPRoute custom resource (CR), such as <toystore>-route.yaml, that has the following information:

    Example HTTPRoute CR

    apiVersion: gateway.networking.k8s.io/v1
    kind: HTTPRoute
    metadata:
      name: <toystore>
      namespace: <${KUADRANT_DEVELOPER_NS}>
      labels:
        deployment: <toystore>
        service: <toystore>
    spec:
      parentRefs:
        - name: <${KUADRANT_GATEWAY_NAME}>
          namespace: <${KUADRANT_GATEWAY_NS}>
      hostnames:
        - api.${KUADRANT_ZONE_ROOT_DOMAIN}
      rules:
        - matches:
            - method: GET
              path:
                type: PathPrefix
                value: /cars
            - method: GET
              path:
                type: PathPrefix
                value: /health
          backendRefs:
            - name: <toystore>
              port: 80

    • Replace <toystore> with the name of your application.
    • metadata.namespace: The namespace in which you are deploying your application. Replace <${KUADRANT_DEVELOPER_NS}> with the environment variable you used during installation.
    • spec.parentRefs.name and spec.parentRefs.namespace: The values must match the Gateway object.
    • spec.hostnames: The hostname must match the one specified in the Gateway object.
    • hostname.rules.matches.backendRefs.name: The name of the Service for your application.
  2. Apply your HTTPRoute CR by running the following command:

    $ oc apply -f <toystore>-route.yaml

    Replace <toystore> with the name of your application.

    Example output

    httproute.gateway.networking.k8s.io/toystore-route created

    The output indicates that the route to the application exists.

Verification

  1. Verify that the HTTPRoute is created by running the following command:

    $ oc get httproute <toystore> -n kuadrant -o=jsonpath='{.status.parents[].conditions[?(@.type=="Accepted")].message}{"\n"}{.status.parents[].conditions[?(@.type=="ResolvedRefs")].message}'

    Replace <toystore> with the name of your application.

    Example output

    Route was valid

  2. If you have DNSPolicy and TLSPolicy objects applied, you can validate that your backend is reachable by running the following command:

    $ curl -k  https://api.${KUADRANT_ZONE_ROOT_DOMAIN}:443/cars

    Note that the example TLSPolicy CR uses a self-signed ClusterIssuer object.

When you want to only allow a certain number of requests for specific users to an API that you are developing, and a general limit for all other users, you can override the default low-limit RateLimitPolicy custom resource (CR).

Important

An existing Gateway-level policy affects new HTTPRoute objects. Because you want users to now access this API, you must override that Gateway policy. For simplicity, you can use API keys to authenticate the requests, but other options such as OpenID Connect are also available.

Prerequisites

  • You installed Connectivity Link on one or more clusters.
  • If you plan to use rate-limiting in a multicluster environment, you have a shared Redis-based datastore.
  • You installed the OpenShift CLI (oc).
  • You have write access to the OpenShift Container Platform namespaces you need to work with.
  • You have access to external or on-premise DNS.
  • You created a Gateway object.
  • You configured your gateway policies and HTTP routes.

Procedure

  1. Create a new RateLimitPolicy custom resource (CR) in a different namespace to override the default low-limit policy and set rate limits for specific users by using the following example:

    Example RateLimitPolicy CR for specific users

    apiVersion: kuadrant.io/v1
    kind: RateLimitPolicy
    metadata:
      name: toystore-rlp
      namespace: ${KUADRANT_DEVELOPER_NS}
    spec:
      targetRef:
        group: gateway.networking.k8s.io
        kind: HTTPRoute
        name: toystore
      limits:
        "general-user":
          rates:
          - limit: 5
            window: 10s
          counters:
          - expression: auth.identity.userid
          when:
          - predicate: "auth.identity.userid != 'bob'"
        "bob-limit":
          rates:
          - limit: 2
            window: 10s
          when:
          - predicate: "auth.identity.userid == 'bob'"

  2. Apply the CR by running the following command:

    $ oc apply -f <toystore-rlp>
    • Replace <toystore-rlp> with the name of your YAML.
    • Wait a few minutes for the RateLimitPolicy CR to be applied.
  3. Check that the RateLimitPolicy has a status of Accepted and Enforced by running the following command:

    $ oc get ratelimitpolicy -n ${KUADRANT_DEVELOPER_NS} toystore-rlp -o=jsonpath='{.status.conditions[?(@.type=="Accepted")].message}{"\n"}{.status.conditions[?(@.type=="Enforced")].message}'
  4. Check that the status of the HTTPRoute is now affected by the RateLimitPolicy CR in the same namespace:

    $ oc get httproute toystore -n ${KUADRANT_DEVELOPER_NS} -o=jsonpath='{.status.parents[0].conditions[?(@.type=="kuadrant.io/RateLimitPolicyAffected")].message}'

Verification

  1. Send requests as user alice by running the following command:

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

    The expected outcome is an HTTP status 200 every second for 5 seconds, followed by HTTP status 429 every second for 5 seconds.

  2. Send requests as user bob by running the following command:

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

    The expected outcome is an HTTP status 200 every second for 2 seconds, followed by HTTP status 429 every second for 8 seconds.

After you deploy your Gateway object, you must expose endpoints, program your HTTP listener, and secure your connections with policies. You can also apply rate-limiting to ensure performance.

Important

In multicluster environments, you must perform all of the steps in each cluster individually, unless specifically excluded.

To complete your deployment, take the following steps:

  • Create and apply a TLSPolicy custom resource (CR) that uses your CertificateIssuer object to set up your HTTPS listener certificates.
  • Create and apply an HTTPRoute or GRPCRoute CR for your Gateway object to communicate with your backend application API.
  • Create and apply an AuthPolicy CR to set up a default HTTP 403 response for any unprotected endpoints.

    Tip

    Use the oc explain authpolicies command to understand which authentication methods are supported when you use Connectivity Link on OpenShift Container Platform. The in-cluster API documentation lists all supported authentication mechanisms.

  • Create and apply a RateLimitPolicy CR to set up a default artificially low global limit to further protect any endpoints exposed by the Gateway object.
  • Create and apply a DNSPolicy CR with a load balancing strategy for your Gateway object.

2.4. About GRPCRoute policy attachment

Beginning with Connectivity Link 1.4.0, GRPCRoute policy attachment is supported. You can now use GRPCRoute custom resources (CRs) for your Remote Procedure Call (gRPC)-native applications and services in all of your Connectivity Link policies except TokenRateLimitPolicy CRs. You can migrate existing policies after you create your GRPCRoute CRs.

Important

GRPCRoute policy attachment is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features offer early access to upcoming product features, enabling customers to test functionality and give feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Connectivity Link policies can now target GRPCRoute resources with the targetRef parameter. Specifically, AuthPolicy and RateLimitPolicy accept GRPCRoute as a valid target kind. The following well-known attributes are also available for Common Expression Language (CEL) expressions:

  • request.grpc.service: Represents the exact service being called.
  • request.grpc.method: Represents the exact function being executed.

Using a GRPCRoute CR instead of an HTTPRoute CR when you already have a gRPC service can be an advantage in the following scenarios:

  • Native service or method matching in routing rules instead of raw path patterns.
  • Clearer intent. The route type declares that this is a gRPC service, making the topology more readable.
  • Gateway API validation. GRPCMethodMatch enforces valid service or method structure rather than free-form path strings.

The following CRs support GRPCRoute CRs in their targetRef fields:

  • AuthPolicy CRs
  • RateLimitPolicy CRs

DNSPolicy and TLSPolicy policies cover attached GRPCRoute CRs automatically.

Telemetry works with GRPCRoute CRs with no updates required. Although telemetry objects target the Gateway object, telemetry captures and reports on gRPC traffic matched by attached GRPCRoute CRs. You have the same level of observability for gRPC traffic as you currently do for traffic routed through HTTPRoute CRs.

Important

Ensure that there is not a mismatch between your Envoy proxy layer and upstream application layers in performing URL normalization.

Envoy serves raw request paths to the wasm-shim component unless normalize_path and merge_slashes are explicitly enabled in the Envoy HTTP Connection Manager (HCM) settings. This means that you can treat /admin and //admin as distinct paths in your CEL predicates, and so on.

However, your application receives the requests. That upstream service can strip redundant slashes or decode URL-encoded values. This means it bypasses your configuration, serving the protected route.

Make sure that you configure your upstream service so that you do not unintentionally bypass your own security. For more information, see Customize your system on path normalization.

2.4.1. Create a GRPCRoute custom resource

You can implement policy attachments based on qualified service and method names by using GRPCRoute policy attachment support. First, you must create a GRPCRoute custom resource (CR).

Important

GRPCRoute policy attachment support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features offer early access to upcoming product features, enabling customers to test functionality and give feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

Prerequisites

  • You installed OpenShift Container Platform.
  • You installed OpenShift CLI (oc).
  • You installed the MCP gateway Operator.
  • You created a Gateway object.

Procedure

  1. Create a GRPCRoute YAML by using the following example:

    Example GRPCRoute CR

    apiVersion: gateway.networking.k8s.io/v1
    kind: GRPCRoute
    metadata:
      name: <grpcstore>
    spec:
      parentRefs:
        - name: <kuadrant_ingressgateway>
          namespace: <gateway_system>
      hostnames: [<"grpc.example.com">]
      rules:
        - matches:
            - method:
                service: <"talker.TalkerService">
                method: <"Echo">
          backendRefs:
            - name: grpcstore
              port: 9000

    See the "GRPCRoute custom resource parameters" reference information for details about parameters.

    Important

    If you include a spec.rules.matches.method block, you must specify a service name, a method name, or both. Omitting the method block entirely matches all gRPC traffic.

  2. Apply your GRPCRoute CR by running the following command:

    $ oc apply -f <grpcstore_route.yaml>

    Replace <grpcstore_route.yaml> with the name of your gRPC YAML.

    Example output

    grpcroute.gateway.networking.k8s.io/grpcstore-route created

    The output indicates that the route to the object exists.

Next steps

  • Create your policies with targetRef values that reference your GRPCRoute CR.
  • If you are migrating HTTPRoute CRs to GRPCRoute CRs, update existing policies to reference your GRPCRoute CR.

2.4.2. GRPCRoute custom resource parameters

You can use the following information about parameters and their values to create a GRPCRoute custom resource (CR) for Connectivity Link.

Table 2.1. GRPCRoute custom resource parameter reference table
ParameterDefinition and Details

metadata.name

The gRPC route name. Replaceable value.

spec.parentRefs.name

The name of the Gateway object to attach this policy to. Replaceable value.

spec.hostnames

List of your public DNS entries. Define this to match the DNS records pointing to your cluster.

spec.parentRefs.namespace

Use this parameter value if your Gateway object is in a different namespace than the route. Use the Gateway object namespace.

spec.rules.matches.method.service

The fully qualified name of the gRPC service from your .proto file. Copy the value exactly from your application code definitions. If you specify a service, but leave the spec.rules.matches.method.method unspecified, the rule applies to all of the functions within this specific gRPC service. You must specify at least one value for the spec.rules.matches.method parameter. Valid values are service or method.

spec.rules.matches.method.method

Use if you want a highly precise filter to isolate a specific function. You must specify at least one value for the spec.rules.matches.method parameter. Valid values are service or method.

spec.rules.backendRefs.name and .port

Point to your application pod. Replace the example values with the name of the service that is running your gRPC application and the port that your application service is listening on.

2.4.3. Migrate policies to GRPCRoute support

Important

GRPCRoute policy attachment support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features offer early access to upcoming product features, enabling customers to test functionality and give feedback during the development process.

For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.

When you want to replace your HTTPRoute custom resources (CRs) with GRPCRoute CRs, you must update your policies to reference a GRPCRoute CR. You must also configure other parameters in those policies as required for your use case.

Important

A GRPCRoute CR cannot coexist with an HTTPRoute CR on the same hostname. If both gRPC and HTTP traffic must share a hostname, use an HTTPRoute CR. Otherwise, use separate hostnames for HTTP and gRPC traffic.

Prerequisites

  • You installed OpenShift Container Platform.
  • You installed OpenShift CLI (oc).
  • You installed the MCP gateway Operator.
  • You created a Gateway object.
  • You have an existing HTTPRoute CR routing traffic to a gRPC service.

Procedure

  1. Delete your HTTPRoute CRs. You must remove the HTTPRoute CR must before you can use the GRPCRoute CR on the same hostname.
  2. Update the spec.targetRef.kind parameter value in your AuthPolicy and RateLimitPolicy CRs to GRPCRoute by using the following example:

    Example AuthPolicy CR updated to gRPC

    #...
    spec:
      targetRef:
        group: gateway.networking.k8s.io
        kind: GRPCRoute
        name: grpcstore
    #...

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top