Simplify Namespace Configuration in WSO2 APK

[steveliem]

Problem

I have successfully configured WSO2 API Platform for Kubernetes (APK) on OpenShift, integrating it with Keycloak as the identity provider. This setup allows for API deployment across multiple namespaces, with each API secured using OAuth2 tokens from Keycloak.

Current Configuration:

• Data Plane Deployment: The APK data plane is deployed in a dedicated namespace.
• Keycloak Integration: A TokenIssuer is configured in APK to facilitate authentication via Keycloak.
• API Deployment: APIs are deployed in various namespaces, each protected by OAuth2 tokens issued by Keycloak.

Issue Encountered:

When deploying an API in a namespace different from the one housing the APK data plane, I encountered a 503 Service Temporarily Unavailable error upon invoking the API with a valid token. Notably, when using an invalid token, the system correctly responds with an Access Token Expired message, indicating that the request reaches the router and undergoes validation.

Solution

Resolution:

The issue was resolved by specifying the relevant namespaces in both the adapter and commonController configurations within the Helm values.yaml file, as follows:

wso2:
  apk:
    dp:
      adapter:
        configs:
          apiNamespaces:
            - "namespace1"
            - "namespace2"
    commonController:
      configs:
        apiNamespaces:
          - "namespace1"
          - "namespace2"

This dual configuration enabled the APK data plane to recognize and manage APIs across the specified namespaces.

Affected Component

Common-controller

Version

1.2.0

Implementation

Improvement Suggestion:

The necessity to list namespaces in two separate sections (adapter and commonController) within the Helm configuration can lead to confusion and potential misconfigurations. Next to that this information is not clearly documented in the Administration guidelines. To enhance user experience and streamline the setup process, I propose consolidating the namespace specification into a single configuration parameter. This approach would simplify the deployment process and reduce the likelihood of errors, thereby improving the overall usability of WSO2 APK in multi-namespace environments.

I appreciate the efforts of the WSO2 team in developing and maintaining APK and hope this suggestion contributes to its continued improvement.

Related Issues

No response

Suggested Labels

helm apk cluster namespace

[steveliem]

Additional Enhancement Suggestion

Building upon the current resolution, I would like to propose a feature request to introduce a more centralized and user-friendly approach for managing namespace configurations.

Feature Suggestion:

Introduce a Custom Resource Definition (CRD):
Instead of maintaining a list of namespaces in the Helm values file, WSO2 APK could benefit from a dedicated CRD. This CRD would allow users to define namespaces dynamically and centralize namespace management. This approach mirrors the implementation in OpenShift Service Mesh Operator, which uses the following CRD:

apiVersion: maistra.io/v1
kind: ServiceMeshMemberRoll
metadata:
  name: default
  namespace: istio-system
spec:
  members:
    # List of namespaces participating in the service mesh
    - your-namespace
    - another-namespace

Benefits:

• Centralized Management: Simplifies namespace configuration and avoids duplication in Helm charts.
• Dynamic Updates: Allows adding or removing namespaces without redeploying or updating Helm charts.
• Improved Usability: Provides a user-friendly experience, aligning with modern practices in multi-namespace setups.

Proposed Implementation:

• Create a CRD (e.g., NamespaceMemberRoll) that is deployed alongside the WSO2 APK data plane.
• This CRD would specify namespaces that the APK data plane should recognize and manage.
• The adapter and commonController components should automatically synchronize with the namespaces listed in this CRD.

This feature would make WSO2 APK more aligned with user expectations for enterprise-grade, multi-namespace Kubernetes environments.

I hope this suggestion can help in making WSO2 APK more robust and easier to use for diverse deployment scenarios. Thank you for considering this proposal.

[steveliem]

Building upon the previous suggestions, I propose an additional feature to enhance the management of namespaces within the WSO2 API Platform for Kubernetes (APK):

Feature Suggestion:

Namespace Annotation for Data Plane Inclusion:
Introduce the capability to include a namespace in the APK data plane by applying a specific annotation to that namespace. This method is inspired by Istio's ambient mode, where namespaces are added to the mesh through labeling. For instance, in Istio, adding the label istio.io/dataplane-mode=ambient to a namespace includes it in the ambient mesh.

Proposed Implementation:

• Namespace Annotation: Users can annotate a namespace with a specific key-value pair (e.g., apk.wso2.com/dataplane=enabled) to indicate its inclusion in the APK data plane.
• Dynamic Detection: The APK control plane components monitor namespaces for this annotation and automatically configure the data plane to manage APIs within these namespaces.

Benefits:

• Simplified Onboarding: Allows for easy and dynamic inclusion of namespaces into the APK data plane without modifying Helm charts or redeploying components.
• Enhanced Flexibility: Empowers administrators to manage namespace participation in the data plane through standard Kubernetes practices.
• Improved User Experience: Reduces configuration complexity, aligning with modern Kubernetes management paradigms.

Implementing this feature would streamline the process of managing multi-namespace environments in WSO2 APK, making it more intuitive and efficient for users.