Skip to content

Security

Security in Satusky is layered. Authentication proves who is calling; authorization decides what they may do; namespace isolation constrains blast radius; encryption protects secrets; machine trust extends that model below Kubernetes.

MechanismCurrent use
API keyCLI and programmatic access
JWT bearer tokenbrowser sessions
internal keyservice-to-service calls

The platform combines global roles and organization-scoped membership. Organization membership is the ordinary tenant boundary; platform admin capability is exceptional.

Each organization maps to a Kubernetes namespace. User-scoped kubeconfigs use service accounts and RBAC limited to that namespace. The control plane itself has broader credentials because it must reconcile platform state.

Secrets are protected in multiple places:

  • encrypted before storage in PostgreSQL,
  • represented as Kubernetes Secrets at runtime,
  • constrained by namespace isolation,
  • shown to users only at creation where applicable.

Bring-your-own-machine workflows add another trust boundary:

machine identity
├── registration / ownership
├── SideroLink connection identity
├── Talos API reachability
└── eventual Kubernetes node membership

The architecture should keep those steps distinct. A machine being visible over SideroLink is not the same as being claimed by a tenant, and a claimed machine is not automatically safe to schedule until the rest of onboarding and policy checks pass.

GapTarget
Machine ownership, claim, and label policies are not yet fully surfaced in public docs.Make fleet trust transitions explicit as machine management matures.
Domain/TLS and endpoint correctness can look like “just networking,” but they are also integrity concerns.Treat reconciliation as a security-adjacent correctness property.
If future nested projects/environments arrive, isolation semantics must be chosen deliberately.Avoid ambiguous pseudo-boundaries that are labels in one place and namespaces in another.