Roles and permissions

Seylo has four roles. They rank viewer < releaser < approver, and admin implies all three.

Role	Can do
viewer	Read: dashboard and matrix, history, requests, resources, environment comparison
releaser	Everything a viewer can, plus: submit releases, create namespaces, add components, propose manifest and environment edits
approver	Everything a releaser can, plus: approve or reject pending requests, and view the audit log
admin	Everything above, plus: register and edit clusters, install and revoke agents, configure single sign-on, manage users and policy

A user holds a set of roles, not one role. The set is the union of everything granted by your identity provider mapping, your organisation’s base roles, and any explicit per-user grant.

Zero roles is a real state

A user who authenticated successfully but whose identity provider granted no mapped role is signed in and authorised for nothing. Every action returns 403.

This is not a bug and it is not a misconfiguration by itself — it is exactly what a correctly configured directory does for someone who has not been granted access yet. Seylo says so explicitly rather than leaving you to discover it: test login reports “no roles” as a finding, with the reason.

How approvals change what a role means

When approvals are enabled — the default once you are using an identity provider — the mutating actions do not apply immediately. A releaser submitting a release creates a pending request; nothing touches the cluster.

• releaser submits → the request is pending.
• approver or admin approves → the same engine code runs, with the original requester preserved as the initiator. The request becomes applied or failed.
• approver or admin rejects → rejected, nothing applied.

One approval is sufficient, and self-approval is allowed

A user who holds approver or admin may approve their own request. This is deliberately not two-person control — the only requirement is that whoever approves holds the role. If you need two-person control, do not grant approver to the people who submit.

A releaser-only user cannot approve, so their request genuinely waits for someone else.

With approvals disabled, mutations apply immediately — but still write audit rows, so there is an audit trail either way.

What roles deliberately do not control

Two boundaries are enforced somewhere other than your role, and knowing where saves an argument later.

The cluster is the real boundary, not the role

A role today has no cluster or namespace dimension. A releaser is a releaser everywhere your organisation has clusters. What narrows reach is:

• the cluster’s namespace allow/deny policy, which applies to everyone equally, and
• the agent’s RBAC posture in that cluster, enforced by Kubernetes itself — see choose an RBAC posture.

If you need a person to be able to deploy to dev but not prod, today that is expressed by which clusters the agent is installed in and with what grant, not by their Seylo role. Per-user cluster and namespace scoping is on the roadmap.

The agent’s own Kubernetes Role is the final word

Whatever your Seylo role says, the agent can only do what its Kubernetes Role/ClusterRole permits. Seylo reads that grant back and shows it to you, so the real boundary is visible before something is refused rather than after.

Administrator vs platform administrator

admin is a role inside your organisation: full control of your clusters, agents, schedules, approvals and SSO, and no knowledge that any other organisation exists.

A platform administrator is a Seylo-side identity that can act across organisations. It is deliberately not a role claim — role claims are minted by your directory, and a customer who can edit their own app roles must not be able to grant themselves the platform. Every platform action is written into both audit trails, so if we act on your data, you can see it in your own audit export.

Next

• Managing users
• Map your directory’s groups to these roles