Separate Kubernetes environments don't have to mean separate clusters. If dev and prod run as two namespaces in one EKS cluster, the bill is probably part of the reason: EKS charges at least $0.10 an hour for every cluster before a single node runs, so a second cluster just for dev adds about $73 a month on its own. The trade-off shows up when you connect an AI agent to that cluster. You want its help in dev, and you want it nowhere near a delete in prod.
In Skyportal, each namespace of a connected cluster can carry its own environment. Label dev as Dev, leave prod on Production, and SARA, Skyportal's agent, can fix things in dev while prod stays read-only. A destructive command aimed at prod is refused before it reaches the cluster. You keep one cluster, one connection and one token, on EKS, GKE or AKS.
Let the token write in dev only
This builds on the setup from the read-only access post: a service account called skyportal in the skyportal namespace, bound to the built-in view role, with its token connected to Skyportal. That token can't change anything. For SARA to fix things in dev, give the same service account the built-in edit role in the dev namespace only:
kubectl create rolebinding skyportal-edit -n dev \
--clusterrole=edit --serviceaccount=skyportal:skyportalA RoleBinding counts only in its own namespace, so the token can now change workloads in dev and still only read prod. The token itself is the same, so there's nothing to update in Skyportal. Keep in mind that edit can read the Secrets in dev and run pods as any service account there. Skyportal never lets an allow list approve a command that touches a Secret, so each of those gets its own approval card.
RBAC and the Skyportal environment do different jobs. RBAC decides what the token can do at all. The environment decides what SARA may try and when it has to ask you first. Keep both: if a label is ever wrong, RBAC still stops the write. This is for a cluster connected with a token. One connected through Skyportal's in-cluster agent refuses every change, whatever the labels say.
Label the namespaces
In the app, find the cluster under Hosts in the left sidebar and click the pencil icon on its row. The Edit Host window has the cluster's own Environment field and, under it, a Namespace environments list with one row per namespace. Every row starts on Inherit, which follows the cluster's environment.
Keep the cluster on Production, set dev to Dev and prod to Production, then click Save Changes. Leave the kubeconfig fields empty and the stored credential stays as it is. prod would inherit Production anyway, but with its own label it gets a tag in the chat's scope picker, and SARA sees the environment next to the name. Every namespace you don't label inherits Production, and so does any namespace you create later.
The list shows the namespaces where Skyportal has seen pods, so a new, empty namespace shows up once something runs in it. Only the cluster's owner can change the labels, and a cluster can hold up to 200 of them. They're set in the web app: from the CLI, skyportalai kubernetes connect --environment sets only the cluster's own environment.
What SARA may do in each environment
Each environment maps to a policy, and the policy decides what happens to a command in that namespace:
- Production is read-only. A destructive command is blocked before it runs, and no approval gets it through. Reads still go through the usual approval card.
- Staging and Custom are standard. A command waits for your approval unless an allow list entry covers it.
- Dev is unrestricted, which for commands means the same approvals as standard.
For kubectl, only reads count as safe: get, describe, logs, top, events and a few more. Everything that changes the cluster is destructive, and so is any verb Skyportal doesn't know as a read, exec, cp and port-forward included. In a prod namespace, SARA can look at pods, logs and events, but a delete, a scale or a rollout restart gets a message like this in the chat:
Blocked: my-eks namespace prod (Production, read-only) reject
destructive commands. Reads still run there.In dev, a namespaced command's approval card also offers Always allow. It saves an allow list entry tied to that namespace, such as kubectl -n dev scale, and the next scale in dev runs without a card. The entry doesn't match the same command in another namespace. Commands on Secrets or RBAC objects, exec, cp, attach, port-forward, and deletes of a namespace, PVC or PV never get Always allow and ask every time.
A policy belongs to the environment name, not to the cluster. If you ever change what Production allows, the change reaches every Production host and namespace you have.
Commands that reach past one namespace
Before it decides, Skyportal works out which namespace a command binds to. kubectl -n dev scale deployment/api --replicas=3 binds to dev. When you pick one namespace in the chat's scope, Skyportal adds the -n for you. With both dev and prod in scope, a command has to name its namespace with -n, or it's refused.
Some commands don't bind to a single namespace: -A, kubectl get nodes, cluster-scoped kinds, manifests passed with -f or -k, anything run with helm, and flags that pick another cluster or identity, such as --context or --as. Those get the strictest policy among all the environments on the cluster. A read like kubectl get pods -A still runs. A change does not: with prod on Production, kubectl apply -f and helm upgrade are blocked in every namespace, dev included.
So keep manifests and Helm releases in your own pipeline, and hand SARA the namespaced work in dev: scaling a deployment, restarting a rollout, changing an image or a memory limit, deleting a stuck pod.
Asking SARA about dev and prod
Pick the cluster in the chat and choose the namespaces SARA may use in the scope picker. A namespace with its own label shows it next to its name, and SARA gets the same labels with the scope, so it knows which namespace is prod before it runs anything. Then ask the way you'd ask a teammate:
- "The worker pods in dev keep getting OOMKilled. Raise the memory limit and restart them."
- "Scale the api deployment in dev to three replicas and check that the pods come up."
- "The checkout pod in prod is crash looping. Find out why and tell me the fix."
In dev you approve each change, or click Always allow for the kinds you trust. In prod SARA reads the logs, events and pod state, and the fix comes back to you as a suggestion. Always allow works on reads there too: allow a kubectl get once in prod, and the next one runs without a card.
Get started
Dev, staging and prod environments are part of the Pro plan. Sign up, connect the cluster with a token, add the edit RoleBinding in dev and label the namespaces. The environment policies guide has the rest of the approval rules.