Cluster Shield with AccesPoint

By Raj Marni. March 28, 2025. Revised. Version 0.0.03

1. Introduction

In the k8or Orbit ecosystem, securing communication between the orbit plane (where management, CI/CD, and orchestration services reside) and the cluster plane (the K3s clusters running workloads) is critical. AccessPoint (Component C52) serves as the Cluster Shield, acting as a centralized gateway that authenticates, authorizes, and routes all requests from orbit-plane components to the cluster plane. By doing so, it enforces security policies, monitors traffic, and ensures that only authorized operations reach the Kubernetes clusters.

This document outlines how AccessPoint operates, details its internal modules, and explains its interactions with other k8or Orbit components such as the Portal, K8Rngr, ArgoCD, SyncMaster, Kaptainer, CodeSource, and others.


2. How AccessPoint Works

2.1 Gateway & Routing

  • Centralized Entry Point:

    • All requests from orbit-plane services (e.g., deployments, log retrieval, scaling commands) must pass through AccessPoint. This includes actions initiated via the k8or Portal (C8), updates from SyncMaster (C56), commands from ArgoCD (C108), and administrative actions from Kaptainer (C62).

  • Multi-Cluster Routing:

    • AccessPoint maintains a registry of target K3s clusters and maps requests to the appropriate cluster based on environment (dev, test, prod) or region.

    • It ensures that commands such as “deploy container” or “fetch logs” are correctly forwarded to the designated cluster’s API server.

2.2 Security & Access Control

  • Authentication:

    • Before routing any request, AccessPoint validates the caller’s identity using tokens, certificates, or SSO credentials provided by the orbit-plane’s IAM.

    • It acts as a security gateway, so individual microservices (like the Portal (C8) or SyncMaster (C56)) do not need direct cluster credentials.

  • Authorization:

    • AccessPoint enforces Role-Based Access Control (RBAC) and additional policy rules to verify that the requesting component is allowed to perform the desired operation on the target cluster.

    • For example, the Portal Deploy Logic can request deployment on a development cluster but might be restricted from altering production environments without proper approvals.

  • Encryption and Secure Communication:

    • All communications between orbit-plane services and the cluster-plane are secured via TLS, ensuring that sensitive data, commands, and responses remain private and tamper-proof.

2.3 Monitoring & Audit

  • Unified Logging:

    • AccessPoint logs every request, including details such as the source (e.g., which orbit-plane component), target cluster, request type, and outcome.

    • These logs integrate with the orbit-plane’s centralized monitoring and audit systems (e.g., InsightHub), providing a comprehensive audit trail for compliance and troubleshooting.

  • Performance Metrics:

    • It collects performance metrics (e.g., request latency, throughput, error rates) and forwards these to monitoring systems like CloudWatch/HelloScope to help administrators detect anomalies or performance bottlenecks.


3. Integration with Other k8or Orbit Components

AccessPoint acts as the common nexus for secure cluster interactions. It interfaces with many other components:

  • Portal (C8):

    • Users initiate actions (deployments, log retrieval) via the Portal, and these actions are routed through AccessPoint to reach the target K3s clusters.

  • K8Rngr (C128):

    • K8Rngr provisions new K3s clusters and uses AccessPoint to manage secure connections for configuration updates, scaling commands, and lifecycle management.

  • ArgoCD (C108):

    • Continuous Deployment operations rely on AccessPoint to securely push application manifests and updates from Git repositories (via CodeSource components like C100 & C96) into the clusters.

  • SyncMaster (C56):

    • Synchronization of state and event propagation across clusters is funneled through AccessPoint, ensuring consistent and secure message delivery.

  • Kaptainer (C62):

    • As a container management GUI, Kaptainer sends commands (e.g., container restarts, scaling requests) to the clusters through AccessPoint.

  • CodeSource (C96/C100):

    • During continuous delivery workflows, updated images and code references are pushed into the cluster via ArgoCD, with all communications secured by AccessPoint.

  • Other Services (e.g., InsightHub, NATS):

    • Monitoring, messaging, and logging components interact with the clusters via AccessPoint, ensuring a secure and audited data flow.


4. Benefits & Impact

  1. Centralized Security Control

    • By funneling all cluster communications through a single gateway, AccessPoint simplifies policy enforcement, ensuring consistent authentication and authorization across the entire ecosystem.

  2. Enhanced Auditability

    • Every request is logged and monitored, providing a clear audit trail for all interactions between orbit-plane services and clusters. This supports compliance and facilitates incident investigations.

  3. Improved System Resilience

    • AccessPoint’s ability to enforce access policies and monitor performance helps prevent unauthorized or malicious actions, enhancing the overall security and resilience of the clusters.

  4. Simplified Integration

    • Other components do not need to manage their own cluster credentials or complex networking setups. They simply send requests to AccessPoint, which abstracts away the intricacies of multi-cluster management.

  5. Scalability and Flexibility

    • New clusters can be added by updating the AccessPoint’s routing registry without modifying individual microservices. This decouples cluster management from service logic, allowing for rapid scaling and adaptation.

Last updated