Skip to main content

Quickstart

This guide sets up access on a new Mission Control installation. By the end, everyone in your organization can browse the catalog, one person can run playbooks on some configs, and a playbook can call an API through a connection.

Remember that Mission Control allows nothing by default. Until you complete step 2, everyone except admins signs in to an empty screen.

1. Sign in as an admin​

On a new installation, only the members of the shipped admins team can manage access:

  • With Kratos or basic auth, sign in as admin@local.
  • With Clerk, sign in as an admin of your Clerk organization.

Bootstrap explains where the password comes from, and how to add more admins.

2. Let everyone browse​

Mission Control ships a viewer Role that reads the catalog, topology, health checks, playbooks, and views. It can't see connections, notifications or anything that configures access, so it's safe to give to everyone.

Give it to everyone by creating a RoleBinding from Settings → Role Bindings:

FieldValue
Rolemission-control-builtin/viewer
People*

* means every person who signs in to Mission Control, including people who sign in later. It doesn't include users of an external identity provider.

3. Let someone run playbooks​

Now let John run playbooks, but only on configs tagged cluster=aws or cluster=demo. Mission Control tags each Kubernetes config with its cluster, see Tags. This takes all three kinds of object:

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

Reading it from the top:

  1. The all-playbooks Scope groups every playbook.
  2. The aws-and-demo-configs Scope groups the configs tagged cluster=aws or cluster=demo.
  3. The john-playbook-run Role has a rule each for running, approving and cancelling those playbooks against those configs.
  4. The RoleBinding gives the Role to John.

Apply it with kubectl apply -f john-playbook-run.yaml, or create the same objects from Settings. john@doe.com is the email John signs in with.

The objects are in the default namespace, but any namespace works. The namespace only groups names: a Role finds a Scope in its own namespace by its bare name, and the namespace of a RoleBinding doesn't limit what it grants. Running a playbook on a config also needs permission to see that config, which John already has from the viewer binding in step 2.

To give the same access to a whole team instead, replace people with teams in the RoleBinding.

4. Let a playbook use a connection​

A playbook acts with its own permissions, not those of the person who runs it. So when a playbook calls an HTTP endpoint through a connection, give the playbook itself permission to use the connection:

playbook-connection.yaml
apiVersion: mission-control.flanksource.com/v1
kind: Scope
metadata:
  name: allow-playbook-connection
  namespace: default
spec:
  targets:
    - connection:
        name: httpbin
        namespace: mc
---
apiVersion: mission-control.flanksource.com/v1
kind: Role
metadata:
  name: allow-playbook-connection
  namespace: default
spec:
  description: allow playbook mc/http-authorized to use connection mc/httpbin
  rules:
    - name: use-connections
      action: connection:use
      resource:
        scopeRef: allow-playbook-connection
---
apiVersion: mission-control.flanksource.com/v1
kind: RoleBinding
metadata:
  name: allow-playbook-connection
  namespace: default
spec:
  role: allow-playbook-connection
  subjects:
    playbooks:
      - name: http-authorized
        namespace: mc

The RoleBinding's subject is the http-authorized playbook, and the Role allows connection:use on the httpbin connection. The Scope is in default but selects a connection in mc: a Scope can select resources in any namespace.

Notifications that send through a connection need a binding like this one too. See Notification permissions. For everything playbooks and other automation may need, see Permissions for automation.

5. Check that it works​

  • Each Scope, Role and RoleBinding has a Ready condition, which kubectl describe shows. Ready=False comes with a reason, such as a Role that names a Scope that doesn't exist.
  • The Subjects page under Settings shows what any person may do, and which rules allow it. Admins can open it, and so can anyone with the shipped access-manage Role.

When something doesn't work​

What you seeWhy, and what to do
Someone signs in and sees nothingNo RoleBinding gives them a Role. Bind viewer to them, their team, or *.
Someone can run a playbook, but not on a particular configThey also need to be able to see that config. Give them read on it, for example through viewer.
A notification fails to sendThe notification needs connection:use on its connection. Add a RoleBinding whose subject is the notification.
A playbook fails to use a connectionThe playbook needs connection:use on the connection. read only lets it see the connection.
A playbook run can't read a config or run another playbookThe playbook itself needs read or playbook:run. Bind a Role to the playbook, not only to the person who runs it.

Next steps​