Access Control
How cluster and service access is managed via SSO and Kubernetes RBAC.
Access to your TrueFullstaq environment is built on Single Sign-On (SSO). You never hold long-lived cluster credentials; every tool logs you in on demand through TrueFullstaq Identity (Keycloak), and what you can do is decided by your SSO group membership combined with Kubernetes RBAC.
# Single Sign-On
One identity unlocks everything:
| Surface | How you authenticate |
|---|---|
| Dashboard (CIK), ArgoCD, Harbor, OpenBao, Grafana (web UIs) | Browser SSO login |
kubectl against the production cluster |
The kubeconfig from your dashboard runs an SSO login (kubectl oidc-login); see Using kubectl |
Behind the scenes, the OIDC issuer is https://login.truefullstaq.com/realms/truefullstaq.
Your authorisation comes from the group /customers/<CUSTOMER_ID>/k8s/admin; membership in
it is what grants you admin over your clusters and services.
# Sessions
SSO tokens are short-lived; when one expires you simply log in again (the browser flow for
web UIs, or transparently on the next kubectl command). To force a fresh login for
kubectl:
kubectl oidc-login clean
# Requesting or changing access
Adding people, or changing who is in your admin group, is handled by your TrueFullstaq engineer. Contact support to request changes.
# Kubernetes RBAC
Once authenticated, the Kubernetes API enforces RBAC on what you can do. Your admin group
maps to broad permissions on your production cluster, while application workloads should run
with their own narrowly-scoped ServiceAccounts.
Cluster-admin of the service cluster is reserved for TrueFullstaq. Your access there is deliberately limited to your own ArgoCD, Harbor, and OpenBao tenancy.
# Give workloads least privilege
Pods get a ServiceAccount token mounted by default. If a pod doesn’t call the Kubernetes
API, turn that off:
spec:
automountServiceAccountToken: false
If it does need API access, create a dedicated ServiceAccount plus a Role/RoleBinding
granting only what it needs. Never reuse the default service account for privileged work.
apiVersion: v1
kind: ServiceAccount
metadata:
name: api
namespace: api
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: api-read-configmaps
namespace: api
rules:
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: api-read-configmaps
namespace: api
subjects:
- kind: ServiceAccount
name: api
namespace: api
roleRef:
kind: Role
name: api-read-configmaps
apiGroup: rbac.authorization.k8s.io
# Secrets
Credentials and API keys must live in OpenBao and reach pods through the External Secrets Operator, never in environment variables baked into images, ConfigMaps, or Git. See Secrets Management and External Secrets Operator.
# A note on support access
For support and break-glass scenarios, TrueFullstaq engineers connect to clusters through a Teleport agent, which records an audit trail of their actions. This is the TrueFullstaq team’s access path. As a customer, you use the SSO + kubeconfig flow described above, not Teleport.