10 lines
3.7 KiB
Plaintext
10 lines
3.7 KiB
Plaintext
Project Sentinel: Remote & Cloud ArchitectureVersion: 3.0.0-EnterpriseModule: 43-Integration-RemoteMaps to: infrastructure/helm/, infrastructure/docker/Scope: Running Sentinel as a centralized service, Kubernetes Sidecar patterns, and Multi-Tenant Cloud deployments.1. The "Cloud Sentinel" ParadigmBy default, Sentinel runs on the developer's laptop (localhost). However, for Enterprise security, relying on the endpoint is insufficient. The Remote Sentinel architecture moves the enforcement layer to a trusted cloud environment.1.1 Architecture Diagramgraph LR
|
|
Dev[Developer Laptop] -->|HTTPS/mTLS| LB[Load Balancer]
|
|
LB -->|Route| Pod[Sentinel Pod]
|
|
|
|
subgraph Kubernetes Cluster
|
|
Pod -->|Sidecar| Agent[Agent Container]
|
|
Pod -->|Mount| VFS[Persistent Volume (Repo)]
|
|
Pod -->|Log| DB[(Cloud SQL)]
|
|
end
|
|
1.2 Use CasesStandardized Dev Environments: Using Coder, Gitpod, or GitHub Codespaces. Sentinel runs as a pre-installed service in the dev container.Centralized Auditing: All logs are streamed directly to a central Splunk/Elasticsearch instance, preventing local tampering.Secret-less Agents: The Agent (Client) has zero secrets. Only the Remote Sentinel (Server) has access to Vault/AWS Secrets Manager.2. Deployment Models2.1 The Kubernetes SidecarIn this model, every Agent instance (e.g., a hosted OpenCode instance) is paired with a Sentinel Sidecar.Communication: Localhost (Loopback) over TCP.Lifecycle: The Agent container dies if the Sentinel container fails (Pod Lifecycle Hook).Volume Sharing: Both share the /workspace volume. Sentinel mounts it Read-Write, but enforces logical locks.2.2 The Central BastionFor local developers connecting to cloud resources.Setup:Developer runs sentinel connect https://sentinel.internal.corp.Local Sentinel acts as a Proxy.All tool execution requests are forwarded to the Remote Sentinel.Remote Sentinel executes the command in the Cloud Sandbox.Benefit: Code never leaves the secure cloud enclave. The local laptop is just a "Thin Client."3. Security & Authentication3.1 Mutual TLS (mTLS)When Sentinel is exposed over a network, it enforces mTLS.Server Cert: Signed by Internal CA.Client Cert: Issued to the specific Developer/Agent identity.Role-Based Access Control (RBAC):Cert OU=Dev -> Can edit_file.Cert OU=Audit -> Can read_logs only.3.2 OIDC / OAuth2Sentinel supports OpenID Connect (OIDC) for user login.Flow:sentinel loginRedirects to Okta/Keycloak.Returns JWT.JWT is passed in Authorization: Bearer header for all API calls.4. Multi-TenancySentinel Cloud can host multiple "Workspaces" on a single instance.4.1 Namespace IsolationConcept: A "Workspace" maps to a Git Repository.API: POST /v1/workspaces { "repo": "github.com/org/app" }Isolation:Each workspace has its own SQLite DB (or distinct tables in Postgres).Each workspace has a dedicated VFS Root.Sentinel ensures Agent A (Workspace A) cannot access paths in Workspace B.4.2 Resource QuotasThrottling:Sentinel enforces CPU/Memory limits per workspace.Rate Limit: Max 100 tool calls per minute per Agent.Cost Limit: Integrated cost tracking prevents a single workspace from draining the OpenAI budget.5. Operations & Observability5.1 Distributed TracingSentinel is instrumented with OpenTelemetry.Trace Context: Propagates from the Agent -> Sentinel Proxy -> Sentinel Core -> Database.Visualization: Jaeger/Tempo traces show exactly where latency is introduced (e.g., "500ms spent in PII regex scanning").5.2 Chaos EngineeringThe Remote Sentinel includes a "Chaos Mode" for testing Agent resilience.Config: chaos_rate = 0.1Effect: 10% of tool calls randomly return "Network Timeout" or "Disk Full".Goal: Verify that the Agent handles errors gracefully and retries correctly, rather than crashing or hallucinating success. |