Migrating from Permissions

Access is lost on upgrade

After upgrading, only members of the shipped admins team keep their access. Everyone else, and every playbook, notification, scraper and canary, loses access to configs and connections until you create Scopes, Roles and RoleBindings for them. Plan the steps below before you upgrade.

Permission and PermissionGroup are deprecated and grant nothing. Scopes, Roles and RoleBindings replace them.

What happens to existing objects

• A Permission or PermissionGroup, whether a Kubernetes resource or one created in the UI, doesn't allow or deny anything.
• A Permission or PermissionGroup applied through Kubernetes is marked Ready=False with reason Deprecated, and nothing of it is stored. Deleting one deletes the row it was stored as, if any.
• Permissions created in the UI are kept, so you can see what they granted and recreate them. They can't be created or changed. Reading them needs read on roleBinding, and deleting them needs delete on roleBinding.
• The old login roles, admin, editor, viewer and guest, are gone. Mission Control now ships ordinary Roles named admin and viewer in the mission-control-builtin namespace. Like any Role, they grant nothing until a RoleBinding binds them. See Shipped Roles.
• A person who used to get a role by signing in gets nothing until a RoleBinding selects them or their team.
• The playbook spec.permissions field, which listed who may run the playbook, grants nothing. Bind a Role with playbook:run on the playbook instead.
• The permissive defaults are gone. Playbooks, notifications, scrapers, canaries and topologies no longer read connections, configs or components without a RoleBinding that selects them. See Permissions for automation.

Map old concepts to new ones

Before	Now
Permission.spec.subject	RoleBinding.spec.subjects: people, teams, playbooks, notifications, scrapers, canaries, topologies or plugins
subject.person: "Jane Doe"	people: [jane@example.com]. An entry is an email, never a name
subject.notification: monitoring/alerts	notifications: [{namespace: monitoring, name: alerts}]
PermissionGroup and subject.group	A team for people, or a list of resource subjects on the RoleBinding
Permission.spec.object and agents, which chose the objects a Permission applied to	A Scope. Use the agent selector field for agent-based permissions
Permission.spec.actions	One Role rule per action
actions: ["*"] or create,read,update,delete	Bind mission-control-builtin/admin, or write one rule per action
playbook:*	Separate rules for playbook:run, playbook:approve and playbook:cancel. Patterns aren't supported
read on a connection, to use it	connection:use. read now only shows a connection, without its credentials
plugin-role:<plugin>:<role>	invoke:<plugin>:<operation> rules, or the shipped plugin-admin Role
deny: true on a Permission	A RoleBinding with deny: true. See Refusing a Role
The admin role	Membership of the shipped admins team, or a RoleBinding to mission-control-builtin/admin
The viewer role	A RoleBinding to mission-control-builtin/viewer
The editor role	A Role of your own with the create, update and delete rules editors need
Identity mapper role output	Map people into teams with a team mapper, and bind Roles to the teams
The system PermissionGroup	Bindings that select each playbook, notification or scraper by namespace and name, with the Roles they need, such as connection:use on their connections and read on configs. There's no system subject

Steps

1. Collect your Permission manifests from Git. For Permissions created in the UI, read them through Mission Control's database API at /api/db/permissions and /api/db/permission_groups, as an admin.
2. Create a Scope for each set of resources the Permissions selected.
3. Create Roles for each set of actions. Keep Roles small and group rules by the Scopes they share.
4. Create RoleBindings that bind each Role to the people, teams and resources that held the Permission. For playbooks and notifications that use connections, bind a Role with connection:use.
5. Check that every new object is Ready=True, and that constrained bindings report AllRulesApply=True.
6. Use the Subjects page under Settings to confirm what each subject may do.
7. Delete the old Permission and PermissionGroup resources.