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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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.
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
Set the
KUADRANT_SYSTEM_NSenvironment variable based on where you created theKuadrantcustom resource (CR) by running the following command:$ export KUADRANT_SYSTEM_NS=$(oc get kuadrant -A -o jsonpath="{.items[0].metadata.namespace}")Create the
Secretcustom 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 EOFApply 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.Create a new
AuthPolicyin a different namespace that overrides thedeny-allpolicy and accepts the API keys. For example, the followingtoystore-auth.yaml:Example user
AuthPolicyapiVersion: 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-idApply the
AuthPolicyCR 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 Copy linkLink copied to clipboard!
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 Copy linkLink copied to clipboard!
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
Gatewayobject. - You have a web application that exposes a port and a TCP endpoint listening for traffic on the port.
-
You created a
Serviceobject for your application. - You have a local Certificate Authority (CA) bundle.
Procedure
Create an
HTTPRoutecustom resource (CR), such as<toystore>-route.yaml, that has the following information:Example
HTTPRouteCRapiVersion: 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.nameandspec.parentRefs.namespace: The values must match theGatewayobject. -
spec.hostnames: The hostname must match the one specified in theGatewayobject. -
hostname.rules.matches.backendRefs.name: The name of theServicefor your application.
-
Replace
Apply your
HTTPRouteCR by running the following command:$ oc apply -f <toystore>-route.yamlReplace
<toystore>with the name of your application.Example output
httproute.gateway.networking.k8s.io/toystore-route createdThe output indicates that the route to the application exists.
Verification
Verify that the
HTTPRouteis 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 validIf you have
DNSPolicyandTLSPolicyobjects applied, you can validate that your backend is reachable by running the following command:$ curl -k https://api.${KUADRANT_ZONE_ROOT_DOMAIN}:443/carsNote that the example
TLSPolicyCR uses a self-signedClusterIssuerobject.
2.2.3. Override the low-limit RateLimitPolicy for specific users Copy linkLink copied to clipboard!
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).
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
Gatewayobject. -
You configured your gateway policies and
HTTProutes.
Procedure
Create a new
RateLimitPolicycustom resource (CR) in a different namespace to override the defaultlow-limitpolicy 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'"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
RateLimitPolicyCR to be applied.
-
Replace
Check that the
RateLimitPolicyhas a status ofAcceptedandEnforcedby 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}'Check that the status of the
HTTPRouteis now affected by theRateLimitPolicyCR in the same namespace:$ oc get httproute toystore -n ${KUADRANT_DEVELOPER_NS} -o=jsonpath='{.status.parents[0].conditions[?(@.type=="kuadrant.io/RateLimitPolicyAffected")].message}'
Verification
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; doneThe expected outcome is an HTTP status
200every second for 5 seconds, followed by HTTP status429every second for 5 seconds.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; doneThe expected outcome is an HTTP status
200every second for 2 seconds, followed by HTTP status429every second for 8 seconds.
2.3. About configuring your Gateway, routes, and policy resources Copy linkLink copied to clipboard!
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.
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
TLSPolicycustom resource (CR) that uses yourCertificateIssuerobject to set up your HTTPS listener certificates. -
Create and apply an
HTTPRouteorGRPCRouteCR for yourGatewayobject to communicate with your backend application API. Create and apply an
AuthPolicyCR to set up a default HTTP403response for any unprotected endpoints.TipUse the
oc explain authpoliciescommand 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
RateLimitPolicyCR to set up a default artificially low global limit to further protect any endpoints exposed by theGatewayobject. -
Create and apply a
DNSPolicyCR with a load balancing strategy for yourGatewayobject.
2.4. About GRPCRoute policy attachment Copy linkLink copied to clipboard!
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.
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
serviceormethodmatching 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.
GRPCMethodMatchenforces validserviceormethodstructure 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.
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 Copy linkLink copied to clipboard!
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).
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
Gatewayobject.
Procedure
Create a
GRPCRouteYAML 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: 9000See the "GRPCRoute custom resource parameters" reference information for details about parameters.
ImportantIf you include a
spec.rules.matches.methodblock, you must specify aservicename, amethodname, or both. Omitting the method block entirely matches all gRPC traffic.Apply your
GRPCRouteCR 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 createdThe output indicates that the route to the object exists.
Next steps
-
Create your policies with
targetRefvalues that reference yourGRPCRouteCR. -
If you are migrating
HTTPRouteCRs toGRPCRouteCRs, update existing policies to reference yourGRPCRouteCR.
2.4.2. GRPCRoute custom resource parameters Copy linkLink copied to clipboard!
You can use the following information about parameters and their values to create a GRPCRoute custom resource (CR) for Connectivity Link.
| Parameter | Definition and Details |
|---|---|
|
| The gRPC route name. Replaceable value. |
|
|
The name of the |
|
| List of your public DNS entries. Define this to match the DNS records pointing to your cluster. |
|
|
Use this parameter value if your |
|
|
The fully qualified name of the gRPC service from your |
|
|
Use if you want a highly precise filter to isolate a specific function. You must specify at least one value for the |
|
| 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 Copy linkLink copied to clipboard!
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.
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
HTTPRouteCR routing traffic to a gRPC service.
Procedure
-
Delete your
HTTPRouteCRs. You must remove theHTTPRouteCR must before you can use theGRPCRouteCR on the same hostname. Update the
spec.targetRef.kindparameter value in yourAuthPolicyandRateLimitPolicyCRs toGRPCRouteby using the following example:Example
AuthPolicyCR updated to gRPC#... spec: targetRef: group: gateway.networking.k8s.io kind: GRPCRoute name: grpcstore #...