Coming in the first release. This page describes behaviour being built for the first Gliss release. Details may change before it ships.
What runs where
What Gliss can do
- Sign releases. Your cluster applies one only if its signature verifies and your policy allows it.
- Relay diagnostics on request, redacted.
- Read diagnostics through a time-limited support access grant that you approve.
- Issue short-lived tokens for the repositories Gliss creates.
What Gliss cannot do
- Log in to your AWS account or cluster. Gliss holds no kubeconfig and no cloud credentials.
- Read secret values. They go from the browser straight to your account.
- See your code. It goes straight from builders’ machines to your Git host.
- Store your logs, unless you opt in to a short retention in the managed tier.
- Run arbitrary commands. Every change, maintenance included, is a signed release.
- Stop your apps. If Gliss cloud is unreachable, apps keep running.
How the cluster connects
The Gliss agent opens one outbound, mutually authenticated TLS connection to Gliss on port 443. The cluster runs no inbound listener for Gliss. A release is applied because its signature verifies, not because of where it came from.Guardrails in the cluster
Each app’s namespace is guarded by an admission policy: only the Gliss agent, system controllers and a break-glass group you name may change workloads there. Apps run as non-root under the restricted pod-security level. Apps reach AWS with their own scoped role, not with keys.A cluster administrator can always remove the guardrails. They protect you from a misconfigured repository, a confused AI or a leaked CI token, not from your own administrators.