Component C52 – AccessPoint

By Raj Marni. March 27, 2025. Revised. Version: 0.0.04

1. Overview

AccessPoint is the gatekeeper that stands between the Orbit Plane (where microservices like Portal Deploy Logic, or Components SyncMaster, ArgoCD, or CommBridge) and the Cluster Plane (where ephemeral or persistent K3s clusters run). All requests—from deploying workloads to pulling logs—flow through AccessPoint to reach the cluster’s API or in‑cluster services. This ensures security, consistency, and auditing are uniformly applied, rather than each service connecting directly to the clusters.

Orbit Component C52 Diagram

2. Internal Modules & Responsibilities

2.1 Gateway / Proxy Core

• Proxy Engine:

  • Terminates or relays incoming requests from the Orbit Plane.

  • Uses reverse proxy logic to forward calls to the correct cluster endpoints (K8s API, custom services).

• Routing & Multi-Cluster Mapping:

  • Maintains a table of clusters (dev, test, prod, etc.) with respective addresses or load balancers.

  • Based on request parameters (like environment name), it selects the target cluster API.

2.2 Security & Policy Enforcement

• Authentication:

  • Validates tokens or certificates from each orbit-plane microservice.

  • Could integrate with the orbit-plane’s IAM or a local trust store.

  • Ensures requests come from known microservices or user sessions with valid roles/permissions.

• Authorization:

  • Compares the requested action (e.g., “POST /deploy/pods in test cluster”) against the configured policy.

  • Could rely on an external policy store or an internal rule set that grants/denies access based on roles, environment constraints, or method type.

• Access Logs:

  • Records essential data (request origin, action, cluster, success/fail) for auditing.

  • Ties in with user-event or error logs in the orbit-plane (e.g., user-error-log-1624 in ChartStore).

2.3 Policy Store / Config

• Local vs. External:

  • AccessPoint can be configured to carry a local policy config or fetch from a separate policy server (OPA, Gatekeeper).

• Policy Updates:

  • Administrators can revise who can do what in each cluster environment without changing code in each orbit-plane microservice.

• Versioning & Rollback:

  • If new policies break expected workflows, the system can revert to a previous policy version.

2.4 Observability & Health

• Metrics & Monitoring:

  • AccessPoint can expose metrics (e.g., request counts, latencies, success/failure rates) to the orbit-plane’s monitoring stack.

• Health Checks:

  • Liveness/readiness endpoints to ensure the gateway is operational. If down, orbit-plane calls to clusters are blocked.

---

3. Data Flows & Process IDs

1. Orbit Plane Service $\rightarrow$ AccessPoint

   • E.g., c8bms15-c52bms03-e20: The Portal Deploy Logic calls AccessPoint to deploy pods in the dev cluster.

   • AccessPoint receives the request, checks tokens/roles.

2. AccessPoint $\rightarrow$ Cluster Plane

   • If authorized, the gateway constructs or passes the request to the relevant K3s cluster’s API or service.

   • E.g., c52bms03-c340breXX-e25 if the cluster-plane resource is identified as c340.

3. Response:

   • The cluster responds with success/fail. AccessPoint logs or flags if an action was denied.

   • The calling orbit-plane service receives a final status or data from the cluster.

---

4. Error Handling & Security Scenarios

1. Invalid Credentials:

   • If the microservice’s token or certificate is expired or unrecognized, AccessPoint denies the request, logs an “unauthorized” error (user-error-log or system logs).

2. Policy Denial:

   • Even if credentials are valid, if the request attempts a disallowed action (e.g., “prod cluster deploy from dev microservice”), AccessPoint denies the request.

3. Service Unavailable:

   • If the target cluster is unreachable or the K8s API times out, AccessPoint returns an error code and logs it for the orbit-plane’s monitoring.

4. Runtime Exceptions:

   • Gateway itself might fail due to config mismatch or network splits. Orbit-plane logs and monitors can capture these events, possibly triggering failovers if multi-instance AccessPoint is used.

---

5. Integration with k8or Orbit Ecosystem

• Orbit Plane:

  • Every microservice (Portal Deploy, SyncMaster, ArgoCD, CommBridge’s Kaptainor, etc.) calls AccessPoint for cluster-plane interactions.

  • They handle user-level logic or multi-service orchestration but rely on AccessPoint for actual cluster communication.

• Cluster Plane:

  • The clusters only see requests coming from AccessPoint, effectively externalizing security.

  • The cluster-plane doesn’t individually trust each orbit-plane microservice—only AccessPoint’s identity or TLS connections.

---

6. Benefits & Impact

1. Centralized Gatekeeping:

   • All cluster-plane calls pass through one gateway, simplifying policy management and logs consolidation.

2. Reduced Complexity:

   • Microservices in orbit-plane don’t need direct cluster credentials or advanced networking routes. They just talk to AccessPoint.

3. Scalable Architecture:

   • Additional clusters can be added by updating routing in AccessPoint, without changing each orbit-plane microservice.

4. Unified Auditing:

   • Access logs, policy rejections, cluster-plane successes/failures are captured in one place, easing compliance or forensic analysis.