Permission

In Mission Control, Permission provides a flexible and strong security model that combines two powerful methods: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). This combined permission system helps you set up detailed access rules. For instance, while RBAC can control if a user can run any playbooks in the system, detailed ABAC rules let you define exactly which playbooks specific users or teams can access.

You can manage Permissions through the UI and using CRDs.

permission.yaml
---
# yaml-language-server: $schema=../../config/schemas/permission.schema.json
apiVersion: mission-control.flanksource.com/v1
kind: Permission
metadata:
  name: allow-user-playbook-run
spec:
  description: |
    allow user john to run any playbook but only on configs in `mission-control` namespace
  subject:
    person: john@doe.com
  actions:
    - playbook:*
  object:
    playbooks:
      - name: "*" # this is a wildcard selector that matches any playbook
    configs:
      - namespace: mission-control

A Permission has 4 parts:

• Subject: The user or service requesting access.
• Object: The resources this permission affects (playbooks, connections, configs, or components).
• Effect: Whether to allow or deny access (Default: allow).
• Actions: The list of allowed actions.

info

Deny rules always override Allow rules.

CRD

Field	Description	Scheme
actions*	List of allowed actions	[]string
deny	Specifies if this is a deny rule. (Default: False)	bool
description	Description of the permission	string
object.components	List of component resource selectors	[]ResourceSelector
object.configs	List of config resource selectors	[]ResourceSelector
object.connections	List of connection resource selectors	[]ResourceSelector
object.playbooks	List of playbook resource selectors	[]ResourceSelector
subject.group	Name of a permission group	string
subject.notification	<namespace>/<name> of the notification	string
subject.person	Email or ID of the person	string
subject.playbook	<namespace>/<name> of the playbook	string
subject.team	Name or ID of the team	string

Additionally, for tag-agent based ABAC, you can also use these fields.

Field	Description	Scheme
agents	List of agents	[]string
tags	Key-value pairs of tags	map[string]string

Subjects

Subjects define WHO or WHAT gets the permission. The subject field can contain only one of the following:

Individual User

Specify a human user by their email address or name (if the name is unique) to grant permission.

subject:
  person: jane.doe@example.com

OR

subject:
  person: "Jane Doe"

Team

Specify a team by its name to grant permission to all its members.

subject:
  team: sre-team

Group

Specify a defined PermissionGroup to grant permission. Groups bundle different items (like specific playbooks, notifications) or lists of users/teams.

subject:
  group: system-administrators

System Services

Sometimes, a specific system service needs permission to act for a particular resource instance. Mission Control often uses this for automation or to allow one part of Mission Control to interact with another. The service gains permission only when it acts for the specified resource, identified by its <namespace>/<name>.

• Notification Service:

  Specify a notification to grant permission to the notification service when it processes that notification. Example: A notification might need access to read a connection or trigger a playbook run.

  subject:
    notification: monitoring/critical-alerts
  

• Playbook Service:

  Specify a playbook to grant permission to the playbook runner service when it runs that playbook. Example: A playbook needs access to a specific resource it acts on.

  subject:
    playbook: automation/cleanup-pods
  

Objects

Objects define the resources the permission targets. You can define Objects using Resource Selectors. There are 4 types of objects:

• Playbooks - Automation playbooks in the system
• Configs - Configuration items in the catalog
• Connections - Connection configurations for external systems
• Components - Topology components

A permission can target multiple objects, while a subject can only target one. If you define multiple objects, Mission Control grants the permission only if the request matches all defined objects. In other words, Mission Control applies an AND condition to the objects.

---
# yaml-language-server: $schema=../../config/schemas/permission.schema.json
apiVersion: mission-control.flanksource.com/v1
kind: Permission
metadata:
  name: allow-user-playbook-run
spec:
  description: |
    allow user john to run any playbook but only on configs in `mission-control` namespace
  subject:
    person: john@doe.com
  actions:
    - playbook:*
  object:
    playbooks:
      - name: "*" # this is a wildcard selector that matches any playbook
    configs:
      - namespace: mission-control

This permission object allows running all playbooks but only on configs in the "mission-control" namespace.

---
# yaml-language-server: $schema=../../config/schemas/permission.schema.json
apiVersion: mission-control.flanksource.com/v1
kind: Permission
metadata:
  name: allow-check-notification-playbook-run
spec:
  description: allow check notification to run playbook
  subject:
    notification: mc/check-alerts
  actions:
    - playbook:run
    - playbook:approve
  object:
    playbooks:
      - name: echo-config

This permission, on the other hand, allows running the "echo-config" playbook on all configs & components.

Permission Actions

The following actions can be used in the actions field of a Permission:

• read - Allows reading resources
• write - Allows creating or modifying resources
• delete - Allows deleting resources
• playbook:run - Allows running playbooks
• playbook:approve - Allows approving playbook runs that require approval
• playbook:cancel - Allows canceling playbook runs

You can also use wildcards to grant multiple permissions at once:

• playbook:* - Grants all playbook-related permissions
• * - Grants all permissions (use with caution)

Permission Groups

Permission Groups let you group subjects (people, teams, or system services) under one name for simpler permission setup. The subjects included in the group then inherit the permissions applied to it.

Permission Groups are particularly useful when:

• You need to manage permissions for many users with similar roles
• You want to grant the same permissions to multiple system services
• You need to update permissions for a set of users all at once

CRD

permission.yaml
---
# yaml-language-server: $schema=../../config/schemas/permission.schema.json
apiVersion: mission-control.flanksource.com/v1
kind: Permission
metadata:
  name: allow-config-notifications-to-run-playbook
spec:
  description: allow config notifications to run playbook
  subject:
    group: config-notifications
  actions:
    - playbook:run
    - playbook:approve
  object:
    playbooks:
      - name: echo-config
---
# yaml-language-server: $schema=../../config/schemas/permissiongroup.schema.json
apiVersion: mission-control.flanksource.com/v1
kind: PermissionGroup
metadata:
  name: config-notifications
spec:
  name: config-notifications
  notifications:
    - name: check-alerts
      namespace: mc
    - name: homelab-config-health-alerts
      namespace: mc

Field	Description	Scheme
name*	Set a unique name for the permission group	string
notifications	List of notification <namespace>/<name>	[]string
people	List of people identifiers (email or id) to associate with the group	[]string
playbooks	List of playbook <namespace>/<name>	[]string
teams	List of team names to associate with the group	[]string