Permissions

Permissions in Mission Control decide what each person, team or automation can see and do. For example, the platform team can run remediation playbooks on staging configs, everyone can browse the catalog, and only a few people can change connections.

Nothing is allowed by default. A new user can't see anything until you grant them access, so everything someone can do is written down in a place you can review.

How it fits together

Access is described with three kinds of object. You can create them from Settings in the UI, or as Kubernetes resources:

• A Scope picks out a set of resources, such as "every config tagged env=staging" or "the playbooks in the monitoring namespace".
• A Role lists what's allowed on those Scopes, such as "read the staging configs" or "run the monitoring playbooks on them". Write a Role once and reuse it for as many people as you need.
• A RoleBinding gives a Role to people, teams, or resources that act on their own, such as playbooks and notifications. A RoleBinding can also narrow the Role to fewer resources, or refuse it outright.

A Scope or a Role on its own grants nothing. Access only starts when a RoleBinding connects a Role to someone. Whoever a RoleBinding gives a Role to is called its subject.

Because RoleBindings decide who can do what, anyone who can create or change them can give themselves any access. Only let people you'd trust as admins manage them.

Example

This manifest lets john@doe.com run, approve and cancel any playbook on configs tagged cluster=aws or cluster=demo:

john-playbook-run.yaml
apiVersion: mission-control.flanksource.com/v1
kind: Scope
metadata:
  name: all-playbooks
  namespace: default
spec:
  targets:
    - playbook:
        name: "*"
---
apiVersion: mission-control.flanksource.com/v1
kind: Scope
metadata:
  name: aws-and-demo-configs
  namespace: default
spec:
  targets:
    - config:
        tagSelector: cluster=aws
    - config:
        tagSelector: cluster=demo
---
apiVersion: mission-control.flanksource.com/v1
kind: Role
metadata:
  name: john-playbook-run
  namespace: default
spec:
  description: allow user john to run any playbook on configs with tags cluster = demo or aws
  rules:
    - name: run
      action: playbook:run
      resource:
        scopeRef: all-playbooks
      target:
        scopeRef: aws-and-demo-configs
    - name: approve
      action: playbook:approve
      resource:
        scopeRef: all-playbooks
      target:
        scopeRef: aws-and-demo-configs
    - name: cancel
      action: playbook:cancel
      resource:
        scopeRef: all-playbooks
      target:
        scopeRef: aws-and-demo-configs
---
apiVersion: mission-control.flanksource.com/v1
kind: RoleBinding
metadata:
  name: john-playbook-run
  namespace: default
spec:
  role: john-playbook-run
  subjects:
    people:
      - john@doe.com

• all-playbooks and aws-and-demo-configs are the Scopes: the playbooks John may use, and the configs he may run them on.
• john-playbook-run is the Role. Each rule pairs an action with the playbooks it acts on (resource) and the configs it acts against (target).
• The RoleBinding of the same name gives the Role to John.

Running a playbook on a config also needs read on that config, so John also needs a Role that lets him read those configs. The Quickstart gives everyone read with the shipped viewer Role.

The example defines its own all-playbooks Scope to keep the manifest self-contained. Mission Control also ships one, mission-control-builtin/all-playbooks, which you can reference instead.

Permission and PermissionGroup are deprecated

Permission and PermissionGroup resources no longer grant anything. Recreate them as Scopes, Roles, and RoleBindings. See Migrating from Permissions.

Next steps

Bootstrap

Quickstart

Scopes

Roles

RoleBindings

Personal Access Tokens

Team Mapping

Migrating from Permissions

Actions Reference

Shipped Roles