## Problem As an Application Operator, I want to run `kubectl` and `helm` commands, so I can troubleshoot, check or modify cluster resources. ## Proposal We should provide users a way to affect their kubernetes cluster in a secure, pre-configured environment. An embedded terminal within the environments page may be one way to accomplish this. Some tools that the user should have access to by default: - `kubectl` (with context preconfigured to connect to the user's cluster) - `helm` - `flux-cli` - `glab` (configured with the user's credentials) ### Architecture/Techincal Proposal As these are all things to be implemented, please see the linked issues below for more details on the individual components. The flow for the whole process looks like the following: ```mermaid sequenceDiagram actor U as User participant G as GitLab participant A as Agent participant K as Kubernetes Cluster U->>G: Select `Terminal` Tab G-)A: Deploy shell image pod A-)+K: Deploy shell image pod create participant P as Pod K->>P: Deploy Pod loop Poll for status G->>+A: Get pod status A->>+K: Get pod status K->>-A: Return status A->>-G: Return status end Note over G,A: When Pod status is Ready G-)A: Pod Attach A-)K: Pod Attach K-)P: Pod Attach P->>G: WebSocket established loop User entering commands U->G: kubectl get pods --all-namespaces G->P: kubectl get pods --all-namespaces P->G: NAMESPACE NAME... end U->>G: exit G->>P: exit P->>G: Websocket disconnected G-)A: delete Pod A-)K: delete Pod destroy P K-xP: delete Pod K-)A: Pod deleted A-)G: Pod deleted ``` The core components are the Pod, the agent and .com. The agent's k8s proxy will allow us to connect to the Pod's attach endpoint via cookie auth, and the WebSocket connection is then wrapped by our javascript client to provide an ergonomic interface for communication with the Pod. The same client also deploys the Pod, and required Service Account, Cluster Role, and Cluster Role Binding. The Service Account allows the User to modify their cluster from within the Pod. As the User has already authenticated, we can give it high-level powers. This Service Account (and resulting Cluster Role and Cluster Role Binding) should be created on first use, and can persist between Web Terminal sessions. All this should be namespaced to allow users to easily clean up objects. ### Future direction We can also think of how to integrate AI via gitlab#412688