Managed identities for workloads
Runseal workers authenticate to Azure using managed identities issued and governed inside the customer's own tenant.
Security
Privileged automation without implicit trust
Zero Trust is not a label added to Runseal. It is expressed in who can request an action, which identity may execute it, what that identity can access and what evidence remains afterwards.
Explicit user authentication
Users authenticate through Entra ID. Browser authentication uses Authorization Code Flow with PKCE, so the browser never holds a client secret.
Server-side authorization
Requests are re-validated server-side. The caller and principal are checked rather than trusted because they reached the platform.
Default-deny access
Access is deny by default. A missing role or ownership assignment fails closed. No assignment means no access.
Role and ownership scoping
Authorization is scoped to the caller's role and to the resources they own. A resource owner sees only what is assigned to them.
Isolated execution permissions
Each worker runs under its own identity and holds its own scoped permissions. Workers do not share a common execution identity, so the reach of any one of them stops at its own domain.
Visibility separated from mutation
The privilege to observe is distinct from the privilege to change. Read paths and write paths are governed independently.
Evidence on every action
Each request and result leaves an operational record that can support investigation and reconciliation.
The safest application credential is the one that was never issued.
Runseal is built so that automating a privileged action does not hand you a new standing credential to defend.