Permissions

Actions

Every action is checked at the platform root: upgrades and platform backups concern the whole platform, so a role assigned on a boundary or below never grants them.

Action	Allows
lifecycle/view	Open the Lifecycle Manager and the Backups page; see components, releases, dependencies, plans, rollouts, installs, drift and backups; check for updates; run the pre-upgrade checks
lifecycle/plan	Create and validate rollout plans; start a platform drift scan with Check now
lifecycle/execute	Execute, resume and cancel a rollout; revert settings changed by hand during a rollout; adopt a setting into the platform configuration; take a platform backup with Back up now
lifecycle/rollback	Roll back a rollout that has ended
lifecycle/install	Install, resume and repair a component
lifecycle/backupsManage	Change the backup target and the daily schedule, pause the schedule, and suspend or resume a database's archiving

Two actions of the RBAC module are used on the After upgrading tab as well: rbac/projector/read, which its Clusters table, View the manifest and the reminder about it need, and rbac/projector/apply, for Apply to all clusters. See Permissions. Platform Reader holds neither, so the Clusters table does not load for it.

Roles

Role, assigned at the platform root	View	Plan, execute, roll back, install	Backup target and schedule
Platform Reader	Yes	No	No
Platform Contributor	Yes	Yes	No
Platform Owner	Yes	Yes	Yes

Platform Owner and Platform Contributor also hold rbac/projector/apply. Applying the access-control roles still runs with your own Kubernetes credentials on each cluster, and each cluster's API server decides what you may write: in practice that is the Platform Owner role.

The platform admin bundle and the commands for a Needs a cluster administrator cluster are outside these roles altogether: they need a cluster-admin kubeconfig.