Red Hat Connectivity Link

By using the OpenShift Container Platform web console with Connectivity Link, different users conduct various API-management tasks, depending on each user’s role-based access and requirements.

The following examples show how you can interact with the Connectivity Link API management section of the web console:

Everyone can explore available APIs without requesting access to them by browsing the API catalog to discover what services are available. Use the API Products page in the main Connectivity Link section to see all of the APIProduct resources in the cluster or current namespace.

API consumers

Developers who need to integrate with services provided by other teams are API consumers. You can use the My API Keys page in the Connectivity Link API Catalog section to see your API key requests.

Use the My API Keys page to complete the following tasks:

Browse your requested API keys
Retrieve your approved credentials
View authentication requirements and service tiers
Request access to APIs

API owner

You are responsible for specific services. Control how your APIs are presented and accessed through the API Products and API Key Approvals pages. You can create new API products, view and edit existing products, configure approval modes, and access detailed product information.

The API Products page is in the main Connectivity Link section and lists all of the APIProduct resources in the cluster or current namespace. Use the API Products page to complete the following tasks:

Define how the API is displayed in the catalog through APIProduct resource metadata
Choose between automatic and manual approval for access requests
Approve or reject requests
Set documentation links so that API consumers can self-serve

The API Key Approvals page is in the Connectivity Link API Catalog section of the web console. Use the API Key Approvals page to complete the following tasks:

Review pending APIKey requests
Approve or reject requests
Add optional comments
View request details
Filter requests by status and API product
Bulk approve or reject requests
Revoke granted access

API administrator

You give cross-team oversight and governance. Use the API Key Approvals page with elevated permissions. The API Key Approvals page is in the Connectivity Link API Catalog section of the web console. Use the API Key Approvals page to complete the following tasks:

View and manage all of the APIProduct resources across the organization
Approve or reject any API key request
Ensure consistency across API products

You can use custom resource definitions (CRDs) to request, grant or remove access to APIs with the Connectivity Link OpenShift Container Platform web console plugin. The following list details available CRDs.

APIProduct: The APIProduct custom resource definition (CRD) wraps an existing HTTPRoute custom resource (CR) with the business context needed for consumption, including a human-readable name, documentation links, contact information, and access policies. When an API owner creates an APIProduct resource and sets the publishStatus field to Published, the API becomes discoverable in the catalog.
APIKey: The APIKey CRD represents the actual API access credentials in the API consumer’s namespace. The controller creates the CRD when an API owner approves an access request.
APIKeyRequest: An APIKeyRequest CRD is a shadow resource in the API owner namespace that enables discovery without exposing API key values. These resources are managed by the Connectivity Link controller and you must not create or modify them manually.
APIKeyApproval: An APIKeyApproval CRD represents an approval or rejection action on an APIKeyRequest resource. API owners and administrators create APIKeyApproval resources to approve or reject pending requests.

You can use one of two authentication methods for protecting APIs with the Connectivity Link OpenShift Container Platform web console plugin.

Configure your chosen method at the platform level through AuthPolicy custom resources (CRs). The Connectivity Link controller automatically discovers AuthPolicy CRs.

API key authentication uses Kubernetes secrets to store credentials. This method is suitable for internal APIs, development environments, or scenarios that require fine-grained control over API access.

The following list is an example workflow:

An API consumer creates an APIKey resource requesting access to an APIProduct resource.
Depending on the APIProduct resource approvalMode field, one of the following events happens:
- Automatic: The controller immediately approves the request.
- Manual: The request enters Pending state, awaiting API owner approval.
For manual approval, the API owner or administrator clicks Approve in the web console.
After approval, credentials become available to the API consumer.
The API consumer retrieves the key from the console and uses it in API requests.
The AuthPolicy CR validates incoming requests against the credentials.

OpenID Connect (OIDC) authentication delegates credential management to an external identity provider. This method is suitable for APIs with the following characteristics:

Integrate with existing identity providers
Require stronger authentication
Need integration with enterprise single sign-on (SSO) systems

No APIKey resources are created. Access control happens at the identity provider level.

There is no request or approval workflow in the OpenShift Container Platform web console for this authentication method, but certain parts of the authentication process are visible. The following list is an example workflow:

A cluster administrator configures an AuthPolicy resource with JWT validation pointing to an OIDC issuer.
The Connectivity Link controller discovers the JSON web token (JWT) authentication scheme and performs OIDC discovery to find the token endpoint.
Discovered authentication details are surfaced in the APIProduct resource status.
An API consumer views the identity provider URL and token endpoint in the web console.
The API consumer obtains a JWT token directly from the identity provider. For example, by using client credentials flow or any other available flow.
The consumer uses the JWT token in API requests.
The AuthPolicy CR validates the token signature and claims against the OIDC issuer.

Important

You can create an OIDCPolicy object in the web console, but this policy is experimental and not supported. If you want to use OIDC authentication in your Connectivity Link deployment, use it with an AuthPolicy object.

When you have an internal API that other teams need to integrate with, you can publish it in a self-service catalog. Then developers can discover it, understand how to use it, and request access with the appropriate credentials.

This process is highly visible with the Connectivity Link OpenShift Container Platform web console plugin.

Prerequisites

You enabled the Connectivity Link OpenShift Container Platform web console plugin.
You created an HTTPRoute custom resource (CR) routing traffic to your API service.
You configured an AuthPolicy CR to protect your API.
You have the api-owner role bound in your namespace.

Procedure

In the OpenShift Container Platform web console, navigate to Connectivity Link → API Products.
Click Create API Product.

Describe your API for consumers by filling in the fields or selecting available options in the following main sections:

API Product Info: Enter the API product’s name, version, and a description that can help other teams understand what your API does and who might want to integrate with it.

Add API and Associate route: Enter the URL to your API spec file, a link to your API documentation, and select an HTTPRoute object.

Tip	Include the following documentation types so that API consumers can self-serve: API reference documentation Getting started guides Code examples or client SDKs Support or contact information

Lifecycle and Visibility: Choose how you want to publish your API. Published makes the API product available for discovery by API consumers. Draft keeps the API product hidden.

API Key Approval: Choose how to manage API key requests.

Automatic: Grant API keys immediately when requested. Use this for internal APIs where you trust all consumers.

Manual: Review each request before approval. Use this when you need to verify use cases or limit access to specific teams.

Note

The system automatically discovers your authentication method from the AuthPolicy CR:

+ * For API key authentication, API consumers request API keys through the web console. * For OpenID Connect (OIDC) or JWT authentication, API consumers can look up your identity provider details and token endpoint.

Click Create.
Optional. After you publish your API product, click your API product from the Name tab, select the Overview tab, then scroll to the end of the page and add your contact information by selecting the pencil icon in each field.

Verification

Confirm that consumers can discover and understand your API by using the web console:
1. Navigate to Connectivity Link → API Products and verify that your API product shows the Published status.
2. Ask a developer from another team to browse the catalog and verify the following information:
  - Your API is displayed in the catalog.
  - The description clearly explains what the API does.
  - Documentation links work.
  - Authentication requirements are visible.

Next steps

Developers can now discover your API in the catalog, request access, and receive credentials.
If you configured manual approval, you can review and approve access requests on the API Key Approvals page.

When you need to call an API owned by another team that is protected with the APIKey authentication method, you can use the OpenShift Container Platform web console.

Browse the internal API catalog and discover available services, then request access. When you are given access, you can receive the credentials in the web console that are required to authenticate your application.

You can select only the API products that use the APIKey authentication method. APIs that use OpenID Connect (OIDC) authentication are available for access depending on your role defined in the AuthPolicy custom resource.

Prerequisites

You enabled the Connectivity Link OpenShift Container Platform web console plugin.
You have the api-consumer role bound in your namespace.
You verified that the API you need is published in the catalog.
You are in your own namespace.

Procedure

Browse the catalog to find an API that solves your problem by using the web console:
1. In the OpenShift Container Platform web console, navigate to Connectivity Link.
2. Select the API Products page.
3. Look for APIs that match your use case based on their display name and description.
Request access to the API by using the web console:
1. In the OpenShift Container Platform web console, navigate to Connectivity Link API Catalog.
2. Select the My API Keys page.
3. Search for and select the API Product you want in the API Product field.
4. If the API offers multiple service tiers, for example, different rate limits, select the tier in the Tier field that matches your traffic requirements.
5. Enter a unique name for your API key resource in the API Key Name field.
6. Describe your use case in the Use Case field so that the API owner understands how you plan to use their service.
7. Click Request.
Wait for approval:
- If the API uses automatic approval, your request is approved immediately and credentials are available.
- If the API requires manual approval, your request enters the Pending state. The API owner reviews your use case and approves or rejects the request.
If you are using the API key authentication method, retrieve the credentials after approval by using the web console:
1. On the My API Keys page, click your approved API key request.
2. In the Credentials section, click Show API Key.
3. The credentials are accessible if the API key is approved. Accessible credentials are labeled with the Active status.
Verify that your API key request is displayed in the My API Keys page with Active status.
Verify that you can call the API by running the following command in your terminal window:
```
$ curl -H "Authorization: Bearer <api_key>" \
  https://<api_hostname>/<api_path>
```
Replace the <api_key>, <api_hostname> and <api_path> API values with the ones required for your use case.
If you are using either the OpenID Connect (OIDC) or JWT authentication method, you can use the web console to get the information needed to request a token and consume the API with the token:
1. In the web console, navigate to the Connectivity Link → APIProducts page.
2. Find the API product that you want.
3. Click the option icons on the API tabs.
4. Select Edit.
5. On the Edit API Product page, navigate to the YAML View.
6. Save the information that you need to request a token.
  Example identity provider URL and credentials YAML snippet
  status: discoveredAuthScheme: authentication: <name>: jwt: issuerUrl: https://keycloak.example.com/realms/myrealm credentials: authorizationHeader: prefix: Bearer
  Example token endpoint URL YAML snippet
  status: oidcDiscovery: tokenEndpoint: https://keycloak.example.com/realms/myrealm/protocol/openid-connect/token
7. Configure your application to obtain JWT tokens from the identity provider by using your credentials. For example, client credentials flow or user login flow.
  
  An API key is not required when your application uses JWT tokens to authenticate.
Verify that you can call the API by running the following command in your terminal window:
```
$ curl -H "Authorization: Bearer <jwt_token>" \
  https://<api_hostname>/<api_path>
```

Next steps

Integrate the API into your application. If you get errors or need help, see the API’s documentation links or contact the API owner by using the information in the API product details.

You can review access requests to verify that consumers have legitimate use cases before granting credentials when you publish an API with manual approval. This helps you know who is using your API so that you can prevent unauthorized or inappropriate usage.

Prerequisites

You enabled the Connectivity Link OpenShift Container Platform web console plugin.
You have either the api-owner role bound in your namespace, or the api-admin role bound cluster-wide.
You published an API product with manual approval mode enabled.
Developers have submitted access requests for your API.

Procedure

Review pending requests in the web console to understand who wants to use your API:
1. In the OpenShift Container Platform web console, navigate to Connectivity Link API Catalog → API Key Approvals.
2. Review the pending API key requests:
  - Requester: Who submitted the request.
  - API Product: Which of your APIs they want to access.
  - Use Case: How they plan to use the API.
  - Tier: If you offer tiers, which service tier they selected.
Decide whether to approve or reject based on the use case:

Approve requests when:
- The use case is legitimate and appropriate for your API.
- The requester team has a valid business need.
- The selected service tier matches their usage requirements.
  
  Reject requests when:
- The use case is unclear or does not match the purpose of your API.
- The requester should use a different API or approach.
- You need more information before approving.
For a single request, take action:

To approve:
1. Click the request.
2. Review the details to confirm the use case makes sense.
3. Click Approve.
4. Optional: Add a comment welcoming the consumer or providing guidance.
5. Click Confirm.
  
  To reject:
6. Click the request.
7. Click Deny.
8. Add a comment explaining why the request was rejected and what the consumer should do instead (for example, "This API is for payment processing. For order status, use the Orders API").
9. Click Confirm.
For many similar requests, use bulk actions:

To bulk approve requests:
1. Select the checkboxes for requests with similar use cases.
2. Click Bulk Approve.
3. Optional: Add a comment that applies to all selected requests.
4. Click Confirm.
  
  To bulk reject requests:
5. Select the checkboxes for requests that share the same issue.
6. Click Bulk Deny.
7. Add a comment explaining the rejection reason.
8. Click Confirm.

Verification

Navigate to Connectivity Link API Catalog → API Key Approvals.
Verify that approved requests show Approved status and rejected requests show Denied status.
For approved requests, confirm that consumers can retrieve credential by asking an approved API consumer to check their My API Keys page and verify that they can view and copy their API key.

Next steps

Approved consumers can now call your API by using their credentials.
Rejected consumers receive your feedback comment explaining why their request was denied and what alternative actions they should take.

Use the following references and concepts to configure role-based access control (RBAC) for API users by using predefined cluster roles and role bindings.

API management enforces strict namespace boundaries:

Consumer namespaces: Consumers manage APIKey and secret resources in their assigned namespaces only.
Owner namespaces: Owners manage APIProduct and APIKeyApproval resources in their team namespaces.
Cross-namespace references: APIKey resources can reference APIProduct resources in other namespaces, but consumers can create APIKey resources only in namespaces where they have role bindings.

API key values are protected through architectural isolation by the following workflow:

The API consumer creates a Secret containing the API key value, then creates an APIKey resource referencing that Secret.
The controller creates an APIKeyRequest shadow resource in the owner namespace and does not contain the API key value.
The API owner creates an APIKeyApproval resource in their namespace.
The controller creates an enforcement Secret in the Connectivity Link namespace, which the API consumer cannot access.
API owners do not see API consumer key values. Even administrators do not have Secret-read permissions in consumer namespaces.

Connectivity Link provides four predefined cluster roles for API management. When you configure ClusterRole objects, include all of the information you need in a single role. Do not name two roles identically to add or change permissions. ClusterRole objects with the same metadata.name parameter value conflict.

The api-catalog-browser role provides cluster-wide read access to API catalog resources for discovery. This role is used by API browsers and permissions are also included in the API owner and API administrator roles.

Example api-catalog-browser permissions

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: api-catalog-browser
rules:
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apiproducts"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["extensions.kuadrant.io"]
    resources: ["planpolicies"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["kuadrant.io"]
    resources: ["authpolicies", "ratelimitpolicies"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["gateway.networking.k8s.io"]
    resources: ["httproutes", "gateways"]
    verbs: ["get", "list", "watch"]

Important

The api-catalog-browser cluster role binding grants cluster-wide read access. There is no way to limit catalog browsing to specific namespaces. All catalog browsers see all published products.

The api-consumer role enables API consumers to create and manage API keys in assigned namespaces. Bind this role in API consumer namespaces by using a RoleBinding resource.

Example api-consumer permissions

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: api-consumer
rules:
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apikeys"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list", "watch", "create", "update", "delete"]

With the api-owner role, you can publish APIs and manage consumer access requests. This role has the following characteristics:

Includes cluster-wide read access for catalog browsing.
Namespace-scoped write access for APIProduct and APIKeyApproval custom definition resources (CRDs).
Owners can view APIKeyRequest custom resources (CRs), but not API consumer APIKey or Secret resources.

Example api-owner role permissions

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: api-owner
rules:
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apiproducts"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apikeyapprovals"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apikeyrequests"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["extensions.kuadrant.io"]
    resources: ["planpolicies"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["kuadrant.io"]
    resources: ["authpolicies", "ratelimitpolicies"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["gateway.networking.k8s.io"]
    resources: ["httproutes", "gateways"]
    verbs: ["get", "list", "watch"]

The api-admin role gives cluster administrators cluster-wide access for management and troubleshooting. This role has the following characteristics:

Same core permissions as api-owner role. but cluster-wide
Additional APIKey write access for troubleshooting
Intentional limitation: No secret read permissions in consumer namespaces

Example api-admin namespace-scoped role permissions

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: api-admin
rules:
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apiproducts"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apikeyapprovals"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apikeyrequests"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["devportal.kuadrant.io"]
    resources: ["apikeys"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
  - apiGroups: ["devportal.kuadrant.io"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["kuadrant.io"]
    resources: ["authpolicies", "ratelimitpolicies"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["gateway.networking.k8s.io"]
    resources: ["httproutes", "gateways"]
    verbs: ["get", "list", "watch"]

With api-owner permissions, you have cluster-wide permissions. You can have the apiGroups "devportal.kuadrant.io" value and the "apiproducts", "apikeyapprovals", "apikeyrequests", resources and can conduct all available actions.
With the apiGroups "devportal.kuadrant.io" value and the "apikeys" resources, you can complete additional troubleshooting tasks with full APIKey access and take all available actions.
Catalog resources are granted with all apiGroups assigned, such as "devportal.kuadrant.io", "kuadrant.io", and "gateway.networking.k8s.io", but you are limited to the "get", "list", and "watch" actions.

After you decide who can access what, you must create a role binding that assigns that list of permissions to those users.

API consumer binding: API consumers require two bindings, both the ClusterRoleBinding object for api-catalog-browser-all-users permissions and a RoleBinding object for api-consumer permissions in their namespace. The RoleBinding object is required for APIKey and Secret management. Catalog browsing is cluster-wide to discover all published APIs, while APIKey and secret management is namespace-scoped and creates team isolation.

Example API consumer ClusterRoleBinding CR

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: api-catalog-browser-mobile-devs
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: api-catalog-browser
subjects:
- kind: Group
  name: mobile-app-developers
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: api-consumer-mobile-devs
  namespace: consumer-team-mobile
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: api-consumer
subjects:
- kind: Group
  name: mobile-app-developers
  apiGroup: rbac.authorization.k8s.io

API owner binding: API owners require one role binding for api-owner in their team namespace. Owners can publish APIs in their namespace and browse the catalog cluster-wide. The api-owner cluster role includes both namespace-scoped management and cluster-wide catalog read access. When bound through a RoleBinding resource, write operations are namespace-scoped, while read operations are cluster-wide.

Example API owner RoleBinding CR

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: api-owner-payments-team
  namespace: api-team-payments
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: api-owner
subjects:
- kind: Group
  name: team-payments
  apiGroup: rbac.authorization.k8s.io

API administrator binding: API administrators require one cluster role binding for api-admin. This role grants access to the API Policies page but not the Overview page.

Example API administrator ClusterRoleBinding CR

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: api-admin-platform-team
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: api-admin
subjects:
- kind: Group
  name: platform-team
  apiGroup: rbac.authorization.k8s.io

You can verify that your role-based-access controls are configured the way you intend by using the CLI.

Note	You can replace `--as-group` with `--as=<username>` or `--as=system:serviceaccount:_<namespace>_:_<name>_` as needed.

Prerequisites

You enabled the Connectivity Link OpenShift Container Platform web console plugin.
You have either the api-owner role bound in your namespace, or the api-admin role bound cluster-wide.
You configured other role bindings as required for your use case.

Procedure

Verify API consumer catalog browsing permissions by running the following command:
```
$ oc auth can-i list apiproducts \
  --as-group=<consumer_group> \
  --all-namespaces
```
- Replace <consumer_group> with the name of the API consumer group.
  Example output
  yes
Verify API consumer APIKey management permissions in their namespace by running the following command:
```
$ oc auth can-i create apikeys \
  --as-group=<consumer_group> \
  -n <consumer_namespace>
```
- Replace <consumer_group> with the name of the API consumer group.
- Replace <consumer_namespace> with a the API consumer namespace.
  Example output
  yes
Verify that API consumers cannot create APIKey resources in other namespaces by running the following command:
```
$ oc auth can-i create apikeys \
  --as-group=<consumer_group> \
  -n <other_namespace>
```
- Replace <consumer_group> with the name of the API consumer group.
- Replace <other_namespace> with a namespace that is not theirs.
  Example output
  no

You can verify that your role-based-access controls are configured the way you intend by using the CLI.

Note	You can replace `--as-group` with `--as=<username>` or `--as=system:serviceaccount:_<namespace>_:_<name>_` as needed.

Prerequisites

You enabled the Connectivity Link OpenShift Container Platform web console plugin.
You have the api-admin role bound cluster-wide.
You configured other role bindings as required for your use case.

Procedure

Verify API owner APIProduct creation permissions in their namespace by running the following command:
```
$ oc auth can-i create apiproducts \
  --as-group=<owner_group> \
  -n <owner_namespace>
```
- Replace <owner_group> with the name of the API owner group.
- Replace <owner_namespace> with the API owner namespace.
  Example output
  yes
Verify that API owners cannot access consumer APIKey resources by running the following command:
```
$ oc auth can-i get apikeys \
  --as-group=<owner_group> \
  -n <consumer_namespace>
```
- Replace <owner_group> with the name of the API owner group.
- Replace <consumer_namespace> with the API consumer namespace.
  Example output
  no

You can verify that your role-based-access controls are configured the way you intend by using the CLI.

Note	You can replace `--as-group` with `--as=<username>` or `--as=system:serviceaccount:_<namespace>_:_<name>_` as needed.

Prerequisites

You enabled the Connectivity Link OpenShift Container Platform web console plugin.
You have the api-admin role bound cluster-wide.
You configured other role bindings as required for your use case.

Procedure

Verify API administrator cluster-wide access by running the following command:
```
$ oc auth can-i list apikeys \
  --as-group=<admin_group> \
  --all-namespaces
```
Replace <admin_group> with the name of the API administrator group.
Example output
```
yes
```

Red Hat Connectivity Link

API management pages in the web console

API management custom resource definitions

API management authentication methods

API key authentication

OIDC and JWT authentication

Publish an API for other teams to discover and consume

Integrate with an API published by another team

Control who can access your published API

API management role-based-access reference

Cluster roles

Role binding requirements

Verify the API consumer access role

Verify the API owner access role

Verify the API administrator access role