Component C52 – AccessPoint
By Raj Marni. March 27, 2025. Revised. Version: 0.0.04
1. Purpose
AccessPoint is effectively the control gate for traffic flowing from orbit-plane components to the ephemeral or persistent K8s clusters in the cluster plane. Whenever a service (e.g., the OpsBoard Deploy Logic, or CommBridge’s Kaptainor) needs to create, retrieve, or modify resources in a K3s cluster, it must route its request through AccessPoint. AccessPoint applies security checks, ensures the caller is authenticated, and enforces authorization policies if the request is permitted to proceed.
2. Key Functions
Secure Gateway
Authentication: Enforces identity checks (e.g., tokens, certificates) for requests entering the cluster plane.
Authorization: Evaluates roles or policies (RBAC, environment restrictions) to confirm the requesting orbit-plane component has the right to perform an action (e.g., deploy a new pod, read logs).
Traffic Encryption: Handles TLS or mutual TLS configurations so data in transit is protected.
Routing & Proxy
Request Forwarding: Re-routes calls to the correct cluster, node, or service in the cluster plane.
Multi-Cluster Support: In multiple K3s clusters (dev/test/prod) environments, AccessPoint ensures the request hits the correct environment.
Connection Management: Maintains stable or ephemeral connections (WebSocket, HTTP/2) as required by orbit-plane component.
Policy & Audit
Policy Enforcement: Integrates with orbit-plane definitions to ensure only certain components can access specific namespaces or APIs.
Auditing: Logs each request’s origin, destination, and outcome for compliance or debugging.
Modular Security Mechanisms
Authentication Methods: Uses OAuth tokens, API keys, certificates.
Authorization Layers: Enforces service-level or operation-level access, e.g., “OpsBoard Deploy Logic can push to dev cluster but not prod”.
Integration: Can be extended with custom code or plugs into other security frameworks (e.g., OPA, Gatekeeper, or a custom policy engine).
3. Architecture & Interactions
3.1 Internal Structure
Gateway:
Core proxy that intercepts all inbound requests from orbit-plane services.
Validates identity tokens, SSL certificates, or other credentials.
Policy Store:
The AccessPoint might reference local or remote policies (in the orbit plane) that define which microservices can perform which actions on which clusters.
Service Registry / Routing:
Maintains a mapping from orbit-plane calls (e.g., “deploy test cluster pods”) to the actual cluster-plane endpoints (K8s API servers or in-cluster services).
3.2 Interactions
Orbit-Plane Service $\rightarrow$ AccessPoint
Example: The k8or Portal’s Deploy Logic calls the cluster-plane’s API to spin up pods. The request is sent to AccessPoint, carrying an identity token or certificate.
AccessPoint Security Checks
AccessPoint verifies the token is valid for the requesting service, checks the request method (e.g., POST to “/deploy”), and consults policy rules.
Forward or Deny
If authorized, AccessPoint routes the request to the corresponding K3s cluster’s endpoint. If not, it logs the attempt and returns an error.
Cluster Response
The cluster plane responds (success/failure), and AccessPoint relays that back to the calling microservice, possibly logging the event.
4. Benefits & Impact
Centralized Security
By funneling all cluster-plane calls through a single gateway, it simplifies the application of consistent authentication/authorization policies.
Policy Flexibility
Administrators can easily adjust who can do what in which cluster, without modifying every microservice’s code.
Audit & Compliance
A single log of cluster-plane accesses makes compliance checks or incident investigations more straightforward.
Network & Protocol Handling
AccessPoint can manage SSL termination, load balancing, or advanced routing (e.g., to multiple clusters) in one place.
Last updated