# Mission Control > Mission Control is Flanksource's Kubernetes-native Internal Developer Platform. Use this file as an entry point to product documentation for architecture, installation, integrations, user guides, and references. **Architecture** Mission Control has a micro-service architecture with a shared data source with multiple deployment models. 1. CLI 2. Kubernetes (Helm Chart) 3. SaaS **Communication Model** Communication between services happens in 3 ways: 1. **Database** - A shared database with interface library enables services to query data that other services own by directly hitting the database using an interface that a shared library provides. 2. **Messaging** - Mission Control uses a Postgres-based message bus; database triggers insert events into queues that various services consume. 3. **HTTP/REST** - Services use this model when they need to interact with systems outside the DB (e.g., the APM hub connects to log stores to retrieve logs). **Postgres** Postgres is the only data store used by Mission Control and relies heavily on JSON and queuing support in Postgres. This limits the dependencies and complexity especially when self-hosting. All services use a shared database and model via the [duty](https://github.com/flanksource/duty) project. This provides the following benefits: - Limit RPC calls improving latency and performance - Services can run with slightly different versions of the library, limiting the need for coordinated migrations - Library updates happen automatically using dependabot ## docs - [Flanksource Mission Control](/docs.md): Flanksource Mission Control is an Internal Developer Platform that helps teams improve developer productivity and operational resilience. - [Architecture](/docs/architecture.md): Mission Control has a micro-service architecture with a shared data source with multiple deployment models. - [Comparison of Mission Control to Backstage](/docs/comparison/backstage.md): https://www.markepear.com/blog/dev-tool-comparison-page - [Git vs Config Focus](/docs/comparison/ci.md): Many automation or playbook journeys begin with GitHub, Jenkins, or similar pipelines that are triggered manually or by an event. This approach works for most scenarios but has some limitations. - [heading 1](/docs/comparison/crossplane.md): Hi - [flux-argo](/docs/comparison/flux-argo.md): DesiredState Store - [overview](/docs/comparison/overview.md): Flanksource Mission Control is a source-open, Kubernetes-native Internal Developer Platform (IDP) that empowers platform teams to improve GitOps adoption and enables developers to gain deeper insights into their systems' state. With Mission Control, you can also easily discover and run GitOps compliant playbooks for day-2 operations. - [prometheus](/docs/comparison/prometheus.md): What is Prometheus? - [Authentication](/docs/connections.md): Mission Control uses the Kubernetes ValuesFrom pattern to retrieve sensitive values like usernames, password and access keys. - [External PostgreSQL](/docs/external-postgres.md): Use a dedicated, empty database owned by the Mission Control login. Run the - [User Guides](/docs/guide.md) - [Audit & Compliance](/docs/guide/audit.md): Mission Control provides audit-ready infrastructure reporting by scraping identity data, infrastructure state, and access logs from your cloud providers, identity systems, and databases into a unified catalog. - [Access Logs](/docs/guide/audit/access-logs.md): Access logs track who accessed configuration items and when. This enables compliance auditing, security monitoring, and access reviews for your infrastructure. - [Applications](/docs/guide/audit/applications.md): This page ties together concepts from Identity & Access, Access Logs, Inventory, and Backups. Read those first if you're new to Mission Control's audit system. - [Backups](/docs/guide/audit/backups.md): Mission Control provides comprehensive auditing for your backup infrastructure, covering health monitoring, storage locations, retention policies, and restore capability. This centralized visibility helps you verify compliance with recovery point objectives (RPOs) and recovery time objectives (RTOs), and ensures your disaster recovery strategy is backed by real evidence rather than assumptions. - [Change Tracking](/docs/guide/audit/change-tracking.md): Mission Control provides an immutable audit trail of all configuration modifications across your infrastructure. It automatically detects and records configuration diffs on each scrape cycle, and ingests external event streams like AWS CloudTrail and Kubernetes events. This detailed log is essential for forensic analysis, incident response, and demonstrating compliance with change management policies. - [Core Concepts](/docs/guide/audit/concepts.md): Mission Control's audit system stores four categories of data: identities (who), permissions (what they can access), access events (what they actually accessed), and resources (infrastructure state). Understanding how these relate is key to building effective audits. - [Identity & Access](/docs/guide/audit/identity-access.md): Mission Control consolidates identity data from disparate sources into a unified catalog, allowing you to track who has access to what across your entire infrastructure. By mapping access to specific applications via the Application CRD, you gain a clear, auditable view of your organization's security posture. This unified perspective is critical for identifying unauthorized access, enforcing least-privilege principles, and meeting regulatory requirements like SOC 2, HIPAA, and ISO 27001. - [Infrastructure Inventory](/docs/guide/audit/inventory.md): Mission Control maintains a complete and up-to-date inventory of all your infrastructure assets, providing a foundational layer for audit and compliance. This catalog details what resources you have, where they are located, and their current health status. A comprehensive inventory is essential for asset management, vulnerability scanning, and demonstrating control over your operational environment to auditors. - [Health Checks](/docs/guide/canary-checker.md): Canary Checker defines and runs periodic health checks against services, infrastructure, and applications. - [Comparisons](/docs/guide/canary-checker/comparisons.md) - [Canary Checker vs Prometheus Blackbox Exporter](/docs/guide/canary-checker/comparisons/blackbox-exporter.md): Prometheus Blackbox Exporter is a Prometheus exporter for probing HTTP, HTTPS, DNS, TCP, ICMP, and gRPC. - [Prometheus Exporters](/docs/guide/canary-checker/comparisons/prometheus-exporters.md): Canary checker can replace the following exporters: - [Concepts](/docs/guide/canary-checker/concepts.md) - [Distributed Canaries](/docs/guide/canary-checker/concepts/distributed-canaries.md): Distributed canaries allow you to define a check once and have it automatically run on multiple agents. This is useful for monitoring services from different locations, clusters, or network segments. - [Expressions](/docs/guide/canary-checker/concepts/expressions.md): canary-checker can be extended using expressions in 3 ways: - [Display Formatting](/docs/guide/canary-checker/concepts/expressions/display-formatting.md): Canary checker can format the results of checks using the display field. All expressions must return a string (or a Go struct with a .String() method) - [Health Evaluation](/docs/guide/canary-checker/concepts/expressions/health-evaluation.md): All checks expose a health status of passing or failing. - [Transformation](/docs/guide/canary-checker/concepts/expressions/transforms.md): The transform can be used to convert one check into multiple checks programmatically. - [Image Variants](/docs/guide/canary-checker/concepts/image-variants.md): Canary checker comes with 3 image variants: - [Metrics](/docs/guide/canary-checker/concepts/metrics.md): Canary Checker works well with Prometheus and exports metrics for every check, the standard metrics included are: - [Request Chaining](/docs/guide/canary-checker/concepts/request-chaining.md): Request chaining allows you to create dependencies between checks within the same Canary, enabling complex multi-step verification workflows. A check can depend on other checks and access their output data through templating. - [Env Vars](/docs/guide/canary-checker/concepts/secret-management.md): Mission Control uses the Kubernetes ValuesFrom pattern to retrieve sensitive values like usernames, password and access keys. - [Examples](/docs/guide/canary-checker/examples.md) - [K6](/docs/guide/canary-checker/examples/k6.md): K6 check runs the k6 load testing suite and ingests the junit exported result in a container at a specified path as defined in testResults. - [Newman](/docs/guide/canary-checker/examples/newman.md): The JUnit check type runs a new kubernetes pod with the specified image, in this example we are running a postman collection test suite using the newman cli. - [Playwright](/docs/guide/canary-checker/examples/playwright.md): The JUnit check type runs a new kubernetes pod with the specified image, in this example we are running a playwright test suite - [SFTPConnection](/docs/guide/canary-checker/examples/sftp.md): Checks the contents of a folder over SFTP for size, age, and count. - [Windows File Share (SMB/CIFS)](/docs/guide/canary-checker/examples/smb.md): Checks the contents of a Windows / CIFS file share for size, age, and count. - [Installation](/docs/guide/canary-checker/installation.md) - [CLI](/docs/guide/canary-checker/installation/cli.md): Installation - [Checks](/docs/guide/canary-checker/reference.md) - [Alertmanager](/docs/guide/canary-checker/reference/alert-manager.md): Fetches alerts from the Prometheus Alertmanager /api/v2/alerts endpoint and stores the alerts in results.alerts. - [CloudWatch](/docs/guide/canary-checker/reference/aws-cloudwatch.md): The CloudWatch check monitors the status of CloudWatch alarms in AWS. It can filter alarms by various criteria and supports transforming alarm data for custom health checks. - [AWS Config](/docs/guide/canary-checker/reference/aws-config.md): The AWS Config check runs a SQL query against AWS Config resources. - [AWS Config Rule](/docs/guide/canary-checker/reference/aws-config-rule.md): The AWS Config Rule check fetches AWS Config rule compliance and fails when matching rules are non-compliant. It skips INSUFFICIENTDATA and NOTAPPLICABLE results. - [Azure DevOps](/docs/guide/canary-checker/reference/azure-devops.md): The Azure DevOps check verifies that the latest completed matching pipeline run succeeded. - [Config DB](/docs/guide/canary-checker/reference/catalog.md): The Catalog check runs a Config DB resource selector query. - [DNS](/docs/guide/canary-checker/reference/dns.md): The DNS check queries DNS records and measures DNS response latency. Use this check to: - [Dynatrace](/docs/guide/canary-checker/reference/dynatrace.md): The Dynatrace check connects to the Dynatrace API and imports Dynatrace problems as check results. - [Elasticsearch](/docs/guide/canary-checker/reference/elasticsearch.md): The Elasticsearch check connects to an Elasticsearch database, runs a query, and verifies the result count. - [Exec](/docs/guide/canary-checker/reference/exec.md): Executes a Bash (Linux) or PowerShell (Windows) script. The check passes when the script exits with 0. - [Folder](/docs/guide/canary-checker/reference/folder.md): The Folder check verifies folder contents by size, age, and count. Folder-based checks are useful for: - [Google Cloud SQL Backups](/docs/guide/canary-checker/reference/gcs-database-backup.md): Checks if a Google Cloud SQL instance has been successfully backed up recently. - [HTTP](/docs/guide/canary-checker/reference/http.md): The HTTP check sends HTTP requests and evaluates the response. - [ICMP](/docs/guide/canary-checker/reference/icmp.md): The ICMP check sends ping requests and measures packet loss, duration, and response. - [JMeter](/docs/guide/canary-checker/reference/jmeter.md): The JMeter check runs the JMeter CLI with a JMX test plan. - [JUnit](/docs/guide/canary-checker/reference/junit.md): Use a JUnit check to run a Kubernetes pod and ingest JUnit XML reports from testResults. - [Kubernetes](/docs/guide/canary-checker/reference/kubernetes.md): The Kubernetes check queries Kubernetes resources such as Pods and evaluates their health or readiness. - [Kubernetes Resource](/docs/guide/canary-checker/reference/kubernetes-resource.md): The Kubernetes Resource check creates Kubernetes resources from the provided manifests and performs checks on them. Use this check to verify that Kubernetes can create resources and that the created resources work as expected. - [LDAP](/docs/guide/canary-checker/reference/ldap.md): The LDAP check: - [MongoDB](/docs/guide/canary-checker/reference/mongo.md): The MongoDB check connects to MongoDB and pings the primary to verify availability. - [OpenSearch](/docs/guide/canary-checker/reference/opensearch.md): The OpenSearch check runs a query against an OpenSearch index and verifies that the hit count equals results. - [Prometheus](/docs/guide/canary-checker/reference/prometheus.md): The Prometheus check connects to Prometheus, runs a PromQL query, and displays the results. - [Pub/Sub](/docs/guide/canary-checker/reference/pubsub.md): The Pub/Sub check connects to a queue, such as Amazon SQS, Google Cloud Pub/Sub, RabbitMQ, Kafka, NATS, or an in-memory queue, and pulls messages. - [Redis](/docs/guide/canary-checker/reference/redis.md): The Redis check connects to a specified Redis database instance to check its availability. - [Restic](/docs/guide/canary-checker/reference/restic.md): The Restic check: - [S3 Protocol](/docs/guide/canary-checker/reference/s3-protocol.md): The S3 protocol check verifies that S3-compatible endpoints, such as MinIO and EMC ECS, can list, put, and get objects. - [SQL](/docs/guide/canary-checker/reference/sql.md): The SQL checks connect to a database, run a query, and fail when the returned row count is less than results. If results is omitted, the threshold is 0. Set markFailOnEmpty: true to fail on zero rows. Use the postgres, mysql, or mssql field for the database engine that you want to check. The following fields apply to all three SQL check types. - [TCP](/docs/guide/canary-checker/reference/tcp.md): The TCP check verifies that a network port is reachable. - [Webhook](/docs/guide/canary-checker/reference/webhook.md): Webhooks allow you to create and update checks by sending HTTP POST requests to an endpoint. - [Scripting](/docs/guide/canary-checker/scripting.md) - [CEL Expressions](/docs/guide/canary-checker/scripting/cel.md): expr expressions use the Common Expression Language (CEL) - [Go Templates](/docs/guide/canary-checker/scripting/gotemplate.md): template expressions use the Go Text Template library with some additional functions provided by the gomplate library. - [Javascript](/docs/guide/canary-checker/scripting/javascript.md): javascript expressions use to the otto Javascript VM - [Security](/docs/guide/canary-checker/security.md): Canary checker is essentially a remote command execution platform, which from a security perspective can be challenging - [Troubleshooting](/docs/guide/canary-checker/troubleshooting.md): Run a Canary from the CLI - [Common Types](/docs/guide/canary-checker/types.md) - [Catalog](/docs/guide/config-db.md): Catalog - [Concepts](/docs/guide/config-db/concepts.md) - [Access Logs](/docs/guide/config-db/concepts/access-logs.md): This page has moved to Audit & Compliance > Access Logs. - [Changes](/docs/guide/config-db/concepts/changes.md): When you save a config item to Config DB, it tracks its changes. These changes come from external sources like Kubernetes events or Azure activities. Alternatively, Mission Control can automatically detect changes by comparing the old config with the new one. - [Health & Status](/docs/guide/config-db/concepts/health_status.md): Each config item has attributes used to determine the health and status of an item. - [Insights](/docs/guide/config-db/concepts/insights.md): Scrapers can create and attach insights (security, performance, cost, etc..) to related config items. - [Plugins](/docs/guide/config-db/concepts/plugins.md): Scrape Plugins are resources that modify the behavior of other scrapers. - [Relationships](/docs/guide/config-db/concepts/relationships.md): The integration charts include many common relationships for Argo, Flux, etc. out of the box. - [Retention](/docs/guide/config-db/concepts/retention.md): After scraping we can choose to retain results on the basis of name, age, count and more. - [Tags](/docs/guide/config-db/concepts/tags.md): Catalog items can have tags attached to them. - [Transformation](/docs/guide/config-db/concepts/transform.md): Transformations allow you to modify scraped config items before they are saved, common use cases include: - [Scrapers](/docs/guide/config-db/scrapers.md): JSON Schema - [AWS](/docs/guide/config-db/scrapers/aws.md): This config type is used to scrape information about your AWS infrastructure. - [Azure](/docs/guide/config-db/scrapers/azure.md): The Azure scrapers scrapes your azure account to fetch all the resources & save them as configs. - [Azure Devops](/docs/guide/config-db/scrapers/azure-devops.md): The Azure Devops scraper will create a new configuration item for each unique pipeline (combination of name and variables). - [Clickhouse](/docs/guide/config-db/scrapers/clickhouse.md): The Clickhouse scraper executes SQL queries against a Clickhouse database or cloud storage systems (AWS S3, Azure Blob Storage) and creates configuration items from the query results. This allows you to treat data stored in Clickhouse or cloud storage as configuration items that can be tracked and monitored. - [Custom Scraper](/docs/guide/config-db/scrapers/custom.md): Full scraper output schema for custom scrapers with users, groups, roles, access logs, and alias resolution - [Exec](/docs/guide/config-db/scrapers/exec.md): The exec scraper runs a script and scrapes the output as configuration items. This is useful for custom integrations where you need to fetch configuration from external systems using scripts. - [File](/docs/guide/config-db/scrapers/file.md): The file scraper is used to create config items from files in a local folder (or git). This can be used to track changes in files like /etc/hosts or /etc/passwd, or for service metadata stored in git. - [GCP](/docs/guide/config-db/scrapers/gcp.md): The GCP scrapers scrapes your GCP account to fetch all the resources & save them as configs. - [GitHub](/docs/guide/config-db/scrapers/github.md): GitHub Actions - [HTTP](/docs/guide/config-db/scrapers/http.md): The HTTP scraper allows you to collect data from HTTP endpoints and APIs. It supports various authentication methods and data transformation capabilities. - [Kubernetes](/docs/guide/config-db/scrapers/kubernetes.md): See the Kubernetes Helm chart that provides a pre-configured Scraper and Topology with some common defaults. - [Kubernetes File](/docs/guide/config-db/scrapers/kubernetes-file.md): The KubernetesFile config type is used to scrape the contents of files inside Kubernetes Pods. - [Logs](/docs/guide/config-db/scrapers/logs.md): The Logs scraper queries log aggregation systems to extract configuration changes from log entries. It supports multiple log backends including Loki, GCP Cloud Logging, OpenSearch, and BigQuery. This allows you to create configuration items and track changes based on log data. - [SQL Server](/docs/guide/config-db/scrapers/mssql.md): The SQL Server scraper uses the SQL scraper to query Microsoft SQL Server databases and create configuration items. This page provides SQL Server-specific examples and queries. - [PostgreSQL](/docs/guide/config-db/scrapers/postgres.md): The PostgreSQL scraper uses the SQL scraper to query PostgreSQL databases and create configuration items. This page provides PostgreSQL-specific examples and queries. - [PubSub](/docs/guide/config-db/scrapers/pubsub.md): The PubSub scraper subscribes to message queues and pub/sub systems to consume messages and create configuration items from them. This enables real-time configuration tracking based on events and messages published to various messaging systems. - [Slack](/docs/guide/config-db/scrapers/slack.md): The Slack scraper monitors Slack channels for messages that contain configuration change information. It uses regular expressions to extract structured data from messages and creates configuration changes based on the extracted information. - [SQL](/docs/guide/config-db/scrapers/sql.md): The SQL scraper executes queries against relational databases and creates configuration items from each row. It supports PostgreSQL, MySQL, and SQL Server, enabling you to: - [Terraform](/docs/guide/config-db/scrapers/terraform.md): The Terraform scraper reads Terraform state files and creates configuration items from the resources defined in the state. This enables you to track your infrastructure as code resources and monitor changes to your Terraform-managed infrastructure. - [Trivy](/docs/guide/config-db/scrapers/trivy.md): The trivy scraper uses Trivy to scan for security vulnerabilities & misconfigurations in your configuration. At the moment, there's only support for scanning Kubernetes objects. - [Tutorials](/docs/guide/config-db/tutorials.md) - [Date Mapping](/docs/guide/config-db/tutorials/date-mapping.md): In this tutorial, you'll use the config-db CLI to scrape a file that consists of a list of virtual machines. - [Scraping Custom Files](/docs/guide/config-db/tutorials/file-scraper.md): In this tutorial you'll scrape the currency conversion rates from a JSON file that comes from this api. - [MCP](/docs/guide/mcp.md): Mission Control supports MCP for those who want to link it with their LLM Clients. - [MCP Client Setup](/docs/guide/mcp/client-setup.md): This guide shows how to connect MCP clients to Mission Control. - [MCP Resources](/docs/guide/mcp/resources.md): Mission Control provides various resources through the MCP interface that can be accessed using URI templates. - [Config Item Resource](/docs/guide/mcp/resources/config_item.md): Access detailed configuration item data from the catalog using the config item's unique ID. - [Connection Resource](/docs/guide/mcp/resources/connection.md): Retrieve connection configuration details by specifying the namespace and name. - [Playbooks Resource](/docs/guide/mcp/resources/playbooks.md): Get playbook with their parameters and metadata. - [MCP Tools](/docs/guide/mcp/tools.md): Mission Control provides various tools through the MCP interface to interact with different aspects of the system. - [Catalog Tools](/docs/guide/mcp/tools/catalog_tools.md): Tools for searching and exploring configuration items in the catalog. - [Connection Tools](/docs/guide/mcp/tools/connection_tools.md): Tools for managing connections in Mission Control. - [Playbook Tools](/docs/guide/mcp/tools/playbook_tools.md): Tools for working with playbooks in Mission Control. - [Notifications](/docs/guide/notifications.md): Mission Control provides a flexible, event-based notification system that enables filtering and templating of notifications via email, push, slack, teams, etc. - [Channels](/docs/guide/notifications/channels.md): Notifications in Mission Control are powered by github.com/containrrr/shoutrrr - [Discord](/docs/guide/notifications/channels/discord.md): discord://token@webhookid - [Email](/docs/guide/notifications/channels/email.md): smtppassword@host:port/?from=fromAddress&to=recipient1[,recipient2,...] - [Generic](/docs/guide/notifications/channels/generic.md): The Generic service can be used for any target that is not explicitly supported by Mission Control, as long as it - [IFTTT](/docs/guide/notifications/channels/ifttt.md): ifttt://key/?events=event1[,event2,...]&value1=value1&value2=value2&value3=value3 - [Matrix](/docs/guide/notifications/channels/matrix.md): Do note that Matrix will discard any information put in the title parameter as the service has no analogue to a - [MatterMost](/docs/guide/notifications/channels/mattermost.md): mattermost://username@]mattermost-host/token[/channel - [Ntfy](/docs/guide/notifications/channels/ntfy.md): Upstream docs//docs.ntfy.sh/publish/ - [Pushbullet](/docs/guide/notifications/channels/pushbullet.md): pushbullet://api-token[/device/#channel/email] - [Pushover](/docs/guide/notifications/channels/pushover.md): pushoverapiToken@userKey/?devices=device1[,device2, ...]&title=Custom+Title&priority=1 - [Rocket.chat](/docs/guide/notifications/channels/rocketchat.md): rocketchat://[username@]rocketchat-host/token[/channel|@recipient]* - [Slack](/docs/guide/notifications/channels/slack.md): The Slack notification service uses either Slack Webhooks or the - [Teams](/docs/guide/notifications/channels/teams.md): teams://group@tenant/altId/groupOwner?host=organization.webhook.office.com - [Telegram](/docs/guide/notifications/channels/telegram.md): Telegram messages are sent with parseMode=MarkdownV2 - [Zulip Chat](/docs/guide/notifications/channels/zulip.md): The shoutrrr service URL should look like this: - [Concepts](/docs/guide/notifications/concepts.md) - [Grouping](/docs/guide/notifications/concepts/grouping.md): Mission Control may generate multiple related notifications within a short time window. Instead of sending each alert, - [Inhibition](/docs/guide/notifications/concepts/inhibition.md): When something breaks in your infrastructure, it rarely breaks alone. A crashing pod makes its ReplicaSet unhealthy, - [Rate Limiting](/docs/guide/notifications/concepts/rate-limiting.md): To prevent overwhelming users with excessive notifications, Mission Control implements a rate limiting mechanism. - [Repeat Interval](/docs/guide/notifications/concepts/repeat-interval.md): The repeat interval determines the duration between subsequent related notifications after an initial successful delivery. - [Silences](/docs/guide/notifications/concepts/silences.md): A silence is a way to temporarily suppress notifications. Each silence has: - [Wait For](/docs/guide/notifications/concepts/wait-for.md): Kubernetes clusters and similar dynamic systems may experience temporary discrepancies between the actual and intended state of resources. - [Events](/docs/guide/notifications/events.md) - [Configs](/docs/guide/notifications/events/configs.md): Events that fire on config changes and health - [Health Checks](/docs/guide/notifications/events/health-checks.md): Events that fire when health checks pass or fail - [Examples](/docs/guide/notifications/examples.md) - [Kubernetes Job Failing](/docs/guide/notifications/examples/kube-job-failing.md) - [Pod CrashLooping](/docs/guide/notifications/examples/kube-podcrashlooping.md) - [Kubernetes Deployment Health](/docs/guide/notifications/examples/kube-unhealthy-deployment.md) - [Permissions](/docs/guide/permission.md): Permissions - [Actions](/docs/guide/permissions/actions.md): Actions define what operations a subject can perform on the target objects. The actions field is required and accepts a list of action strings. - [Scopes](/docs/guide/permissions/concepts/scope.md): Scopes define collections of resources that can be used for fine-grained access control in Mission Control. A Scope allows you to group resources by various criteria (agent, namespace, name, tags) and use these groups in permission rules to control who can access what resources. - [Examples](/docs/guide/permissions/examples.md) - [Combining Selectors](/docs/guide/permissions/examples/combining-selectors.md): Within a single ScopeResourceSelector, you can combine multiple fields. All specified fields must match (AND logic). - [Global Resource Selectors](/docs/guide/permissions/examples/global-resource-selectors.md): The global resource type creates a Scope that applies to all resource types simultaneously. This is useful for namespace-wide or agent-wide restrictions. - [Multi-Tenancy Patterns](/docs/guide/permissions/examples/multi-tenancy-patterns.md): Scopes are fundamental to implementing multi-tenancy in Mission Control. Here are common patterns for partitioning resources across different tenants, teams, or organizational units. - [Multiple Resource Types](/docs/guide/permissions/examples/multiple-resource-types.md): A single Scope can include multiple resource types by using multiple targets. Each target must specify exactly one resource type, and targets are combined with OR logic. - [Targeting by Agent](/docs/guide/permissions/examples/targeting-by-agent.md): This example shows how to scope configs based on which agent reported them. This is useful for creating permissions that apply to specific infrastructure components or regions. - [Targeting by Tags](/docs/guide/permissions/examples/targeting-by-tags.md): This example shows how to use tag selectors to dynamically scope resources based on their labels. Tag-based scoping is the most flexible approach because you can add or remove resources from the scope by simply updating their tags. - [Targeting Canaries](/docs/guide/permissions/examples/targeting-canaries.md): This example demonstrates scoping canary health checks by name. - [Targeting Specific Playbooks](/docs/guide/permissions/examples/targeting-specific-playbooks.md): This example demonstrates how to create a Scope that targets specific playbooks by name within a namespace. - [Targeting with Wildcards](/docs/guide/permissions/examples/targeting-with-wildcards.md): This example demonstrates using the wildcard * to match all resources of a specific type. - [Groups](/docs/guide/permissions/groups.md): Permission Groups let you group subjects (people, teams, or system services) under one name for simpler permission setup. - [Multi Tenancy / ABAC](/docs/guide/permissions/multi-tenancy.md): Mission Control provides sophisticated access control mechanisms for complex deployment scenarios, particularly in Software-as-a-Service (SaaS) environments where multiple tenants or organizations share the same infrastructure. - [Permission](/docs/guide/permissions/permission.md): A Permission defines access control rules that grant or deny specific actions to subjects on target objects. - [Quickstart](/docs/guide/permissions/quickstart.md): This guide helps you get started with Mission Control permissions, including understanding default permissions and how to customize them. - [Roles](/docs/guide/permissions/roles.md): Mission Control uses Role-Based Access Control (RBAC) to manage access to resources based on the roles assigned to users. - [Subjects](/docs/guide/permissions/subjects.md): Subjects define WHO or WHAT gets the permission. The subject field can contain only one of the following: - [Playbooks](/docs/guide/playbooks.md): Playbooks - [Actions](/docs/guide/playbooks/actions.md): Actions are the fundamental tasks executed by a playbook. A playbook can comprise multiple actions, which are executed sequentially. If any action encounters an error and fails, the execution of the playbook is halted. - [AI Action](/docs/guide/playbooks/actions/ai.md): AI Action allows you to integrate AI capabilities into your playbooks by leveraging the rich context that Mission Control maintains about your infrastructure. When executed against configs or components, the AI action automatically injects: - [Azure DevOps Pipeline Action](/docs/guide/playbooks/actions/azure_devops_pipeline.md): This action allows you to invoke pipelines in your Azure DevOps project. - [Exec Action](/docs/guide/playbooks/actions/exec.md): Exec action allows you to executes a command or a script file on the target host. The type of scripts executed include: - [GitHub Action](/docs/guide/playbooks/actions/github.md): GitHub Action allows you to invoke GitHub workflows from the playbooks. - [GitOps Action](/docs/guide/playbooks/actions/gitops.md): The GitOps action creates commits and pushes changes to a git repository. - [HTTP Action](/docs/guide/playbooks/actions/http.md): HTTP action makes an HTTP request. - [Logs Action](/docs/guide/playbooks/actions/logs.md): The Logs action fetches and queries logs from various backends. Use it to retrieve logs for debugging, analysis, or to pass to downstream actions like AI analysis. - [Notification](/docs/guide/playbooks/actions/notification.md): Notification action sends notification. - [Pod Action](/docs/guide/playbooks/actions/pod.md): Pod action allows you to run an arbitrary pod on your kubernetes cluster. - [SQL Action](/docs/guide/playbooks/actions/sql.md): SQL action makes a SQL query on the provided database. - [Concepts](/docs/guide/playbooks/concepts.md) - [Approvals](/docs/guide/playbooks/concepts/approval.md): Approval mechanisms ensure that only authorized individuals or teams can execute playbook runs. This safeguard helps maintain control and security over critical operations. - [Artifacts](/docs/guide/playbooks/concepts/artifacts.md): Artifacts allow you to archive files generated by playbook actions to a file store of your choice. - [Cancel Runs](/docs/guide/playbooks/concepts/cancellation.md): You can manually end running playbooks at any time through the Mission Control interface. - [Expressions](/docs/guide/playbooks/concepts/expression.md): Playbook event filters use Common Expression Language (CEL). - [Runners](/docs/guide/playbooks/concepts/runners.md): Playbook runners offer the flexibility to designate where actions are executed. By default, actions run on the main instance, but a set of agents can also be provided and one of them will be chosen at random. - [Sensitive Data](/docs/guide/playbooks/concepts/sensitive-data.md): Sensitive data includes passwords, API keys, tokens, and other confidential information that requires protection from unauthorized access or exposure. Mission Control provides comprehensive protection for sensitive data throughout the entire playbook lifecycle. - [Templating](/docs/guide/playbooks/concepts/templating.md): You can use templating to access data from your configs, health checks, and components. Templates allow you to create reusable playbooks by - [Timeouts](/docs/guide/playbooks/concepts/timeout.md): Set timeouts on playbooks to automatically cancel their execution after a specified duration. This helps prevent playbooks from running for too long and consuming resources. - [Event Triggers](/docs/guide/playbooks/events.md): Playbook events are triggers that cause a Playbook to run. Events are triggered when specific activity on Mission Control occurs. - [Examples](/docs/guide/playbooks/examples.md) - [Conditional Actions](/docs/guide/playbooks/examples/action-filter.md): Conditional actions allow you to execute specific actions based on the success or failure of previous actions. - [Introduction](/docs/guide/playbooks/examples/action-filter-action-result.md): This example demonstrates how to reuse the output of one action in a playbook to conditionally execute another action. This is useful for creating dynamic workflows based on the results of previous actions. - [Introduction](/docs/guide/playbooks/examples/approval.md): This example demonstrates how to create a playbook that requires approval before execution. The playbook scales a Kubernetes deployment to a specified number of replicas. The approval process ensures that either an admin or a member of the DevOps team approves the action before it runs. - [Delayed Actions](/docs/guide/playbooks/examples/exec-delay.md): Delay - [JIT Access via GitOps](/docs/guide/playbooks/examples/gitops-k8s-cluster-role-binding.md): Screenshots - [JIT Access With Expiry](/docs/guide/playbooks/examples/kubectl-cluster-role-binding.md): Screenshots - [Kubectl Logs](/docs/guide/playbooks/examples/kubectl-logs-artifacts.md): Screenshots - [Auto Delete Pods](/docs/guide/playbooks/examples/restart-pod-on-check-failure.md): Restart pod when check fails for more than 10 times in the last hour - [Quick Start](/docs/guide/playbooks/quick-start.md): In this walk-through, we create and run a playbook that scales a Kubernetes deployment. - [Self Service](/docs/guide/playbooks/self-service.md): Playbooks can be manually triggered on a component, config item or check. - [Webhook Triggers](/docs/guide/playbooks/webhooks.md): Playbooks can also be triggered via webhooks. When a webhook is configured, mission-control listens on the specified endpoint and any calls to the endpoint triggers the playbook. - [Table](/docs/guide/table.md): Tables are the primary way to explore view data in Mission Control. They render rows from your queries, apply mappings, and drive filters, cards, and links into configs or other views. - [Views](/docs/guide/views.md): Views are dynamic, data-driven dashboards in Mission Control that aggregate and visualize data from multiple sources. - [Concepts](/docs/guide/views/concepts.md) - [Cache Control](/docs/guide/views/concepts/cache-control.md): Views implement intelligent caching to minimize unnecessary data refreshes while keeping data reasonably fresh. Cache control settings help you balance data freshness with performance. - [Variables](/docs/guide/views/concepts/templating.md): Variables make views interactive by allowing users to dynamically control which data is fetched. Variables are defined in the templating section and their values are substituted into queries using the $(var.) syntax. - [Examples](/docs/guide/views/examples.md): This page provides practical examples of Views for common use cases. Each example demonstrates different features and patterns you can apply to your own dashboards. - [Database Backups](/docs/guide/views/examples/database-backups.md) - [Deployment Monitoring](/docs/guide/views/examples/deployment-monitoring.md) - [Pipeline Monitoring](/docs/guide/views/examples/pipeline-monitoring.md) - [Panels](/docs/guide/views/panels.md): Panels display aggregated data visualizations above the main table. Each panel runs a SQL query against the view's query results and renders the data as a chart, gauge, or summary. - [Bar Gauge](/docs/guide/views/panels/bargauge.md): The bargauge panel displays multiple values as horizontal bars with configurable thresholds. Useful for comparing related metrics like CPU real usage vs requests vs limits. - [Duration](/docs/guide/views/panels/duration.md): The duration panel displays time duration values in a human-readable format (e.g., "2h 30m"). It has no additional configuration properties. - [Gauge](/docs/guide/views/panels/gauge.md): The gauge panel displays a single numeric value as a visual gauge with configurable min/max bounds and color thresholds. - [Number](/docs/guide/views/panels/number.md): The number panel displays a single numeric value with optional unit formatting. - [Piechart](/docs/guide/views/panels/piechart.md): The piechart panel displays data distribution as a pie chart with customizable colors and labels. - [Properties](/docs/guide/views/panels/properties.md): The properties panel displays a single row of data as a vertical list of key-value pairs. This is useful for showing details of a specific entity. - [Table](/docs/guide/views/panels/table.md): The table panel displays query results as a simple key-value list. It has no additional configuration. - [Text](/docs/guide/views/panels/text.md): The text panel renders free-form text rows. Use it for short notes, callouts, or contextual guidance above the table. - [Time Series](/docs/guide/views/panels/timeseries.md): The timeseries panel visualizes data over time using line, area, or point charts. - [Queries](/docs/guide/views/queries.md) - [Change Queries](/docs/guide/views/queries/changes.md): Change queries retrieve the audit trail of modifications to configuration items. - [Config Queries](/docs/guide/views/queries/configs.md): Config queries fetch configuration items from the Flanksource catalog. - [HTTP](/docs/guide/views/queries/http.md): The http query allows you to fetch data from external APIs and use it within your view. It supports RESTful APIs and can extract data using JSONPath. - [Prometheus Queries](/docs/guide/views/queries/prometheus.md): Prometheus queries fetch metrics directly from Prometheus using PromQL. - [SQL Queries](/docs/guide/views/queries/sql.md): Use sql to run queries against external databases (PostgreSQL, MySQL, or SQL Server) and feed the results into a view. SQL queries share the same templating and mapping capabilities as other data sources. - [View Table Selector Queries](/docs/guide/views/queries/view-table-selector.md): View table selectors reuse cached data from other views instead of hitting the original data sources again. They are ideal for composing dashboards, drilldowns, or summaries on top of existing views. - [Columns](/docs/guide/views/table/columns.md): Tables define the structure and display of view data. Each column has a type that controls how values are rendered and filtered. - [Badge](/docs/guide/views/table/columns/badge.md): The badge column type displays text values as styled badge/tag elements. Useful for categories, labels, and versions. - [Boolean](/docs/guide/views/table/columns/boolean.md): The boolean column type renders true/false values as friendly yes/no text in tables and cards. Use it for readiness, feature flags, or any binary state. - [Bytes](/docs/guide/views/table/columns/bytes.md): The bytes column type displays byte sizes with automatic unit formatting (B, KB, MB, GB, TB). - [Config Item](/docs/guide/views/table/columns/config-item.md): The config_item column type displays clickable links to configuration item detail pages with a proper icon. - [DateTime](/docs/guide/views/table/columns/datetime.md): The datetime column type displays timestamps with human-readable formatting. - [Decimal](/docs/guide/views/table/columns/decimal.md): The decimal column type displays numeric values with support for high precision. Use it for floats, ratios, costs, and any value where decimal accuracy matters. - [Duration](/docs/guide/views/table/columns/duration.md): The duration column type displays time spans in human-readable format (e.g., 2h 30m, 1d). Values are expected in nanoseconds. - [Gauge](/docs/guide/views/table/columns/gauge.md): The gauge column type displays numeric values as visual gauges with configurable thresholds and colors. - [Health](/docs/guide/views/table/columns/health.md): The health column type displays health status with color-coded indicators. Supports three states: healthy (green), warning (yellow), and unhealthy/critical (red). - [Labels](/docs/guide/views/table/columns/labels.md): The labels column type renders key/value labels and supports include/exclude filtering by tag. Values must be a JSON object (e.g., {team "prod"}). - [Millicore](/docs/guide/views/table/columns/millicore.md): The millicore column type displays CPU resources in millicores (1000m = 1 CPU core). - [Number](/docs/guide/views/table/columns/number.md): The number column type displays numeric values (integers and decimals). - [Status](/docs/guide/views/table/columns/status.md): The status column type displays status values with appropriate styling. Common values include Running, Pending, Failed, Succeeded, etc. - [String](/docs/guide/views/table/columns/string.md): The string column type displays text values. - [How It Works](/docs/how-it-works.md): Mission Control manages configuration primarily through Custom Resource Definitions (CRDs). While a postgres database serves as the ultimate source of truth, Kubernetes operators ensure continuous synchronization between the CRDs and the database. By using the database as the source of truth Mission Control provides the best of both worlds. - [Installation](/docs/installation.md): Deployment Model - [Artifacts](/docs/installation/artifacts.md): Filestores - [Helm](/docs/installation/helm.md): values.yaml - [Local Testing](/docs/installation/local-testing.md): Run Mission Control Locally using minikube or kind - [Monitoring & Tracing](/docs/installation/monitoring-and-tracing.md): Notifications - [Agent Installation](/docs/installation/saas/agent.md): To install and run the Mission Control agent you need to have the following prerequisites: - [Install Mission Control Agent on an AWS EKS cluster](/docs/installation/saas/eks.md): To install and run Mission Control you need to have the following prerequisites: - [Getting Started](/docs/installation/saas/getting-started.md): When using the Mission Control SaaS the agent based approach is recommended for ingesting data, The agent is headless installation of mission-control that caches data locally in a postgres database and replicates it to the SaaS. - [Install Mission Control Agent on an AWS EKS cluster](/docs/installation/saas/gke.md): To install and run Mission Control you need to have the following prerequisites: - [Kubectl Access](/docs/installation/saas/kubectl.md): Mission Control SaaS instances are deployed on dedicated vCluster instances. - [Getting Started](/docs/installation/self-hosted.md): Mission Control is an internal developer platform built for operations. Built with a "self-hosted first" approach, Mission Control gives you complete control over your deployment environment while offering enterprise-grade features. - [Database](/docs/installation/self-hosted/database.md): Alternative methods for connecting to the db used for persistence - [Self Hosted Installation on AWS EKS](/docs/installation/self-hosted/eks.md): To install and run a self-hosted Mission Control on AWS EKS you need to have the following prerequisites: - [Self Hosted Installation on GCP GKE](/docs/installation/self-hosted/gke.md): To install and run a self-hosted Mission Control on GCP GKE you need to have the following prerequisites: - [SMTP / Email](/docs/installation/self-hosted/smtp.md): An SMTP server is required for sending notifications, approvals, user invites and password resets. - [Single Sign On (SSO)](/docs/installation/self-hosted/sso.md): Mission Control uses kratos for identity management. Login via email/password is the default flow but any OIDC provider supported by Kratos can be used. - [Integrations](/docs/integrations.md): Mission Control integrates with a wide range of platforms and services. Each integration supports different capabilities: - [ArgoCD](/docs/integrations/argo.md): Mission Control integrates with ArgoCD to provide visibility into your GitOps deployments. - [AWS](/docs/integrations/aws.md): Mission Control integrates with AWS to provide visibility into your cloud infrastructure, monitor resource health, and automate remediation workflows. - [AWS Config](/docs/integrations/aws/config.md): Mission Control integrates with AWS Config to monitor your AWS resource configurations and compliance. Use it to: - [Getting Started](/docs/integrations/aws/getting-started.md): Installs a catalog scraper that: - [IAM](/docs/integrations/aws/iam.md): Depending on how you want to use Mission Control you need to create an IAM role for mission control to use: - [Azure](/docs/integrations/azure.md): Mission Control integrates with Azure to provide visibility into your cloud infrastructure. - [Azure AD / Entra ID](/docs/integrations/azure-ad.md): Mission Control scrapes identity data from Entra ID and stores it in a unified catalog alongside your infrastructure (AWS, Azure, Kubernetes, SQL Server, Azure DevOps) and custom applications. The Application CRD maps this catalog data into access and audit reports — giving you a single view of who has access to what, when they last used it, and whether it's been reviewed. - [Audit Logs](/docs/integrations/azure-ad/audit-logs.md): Entra ID generates sign-in logs and directory audit logs that Mission Control scrapes as access logs. There are three approaches depending on your infrastructure and latency requirements. - [Event Hub Streaming](/docs/integrations/azure-ad/audit-logs/event-hub.md): For real-time, high-volume ingestion, stream Entra logs via Azure Event Hub. This provides the lowest latency but requires the most infrastructure setup. - [HTTP + MS Graph](/docs/integrations/azure-ad/audit-logs/http-scraper.md): The simplest approach: poll the Microsoft Graph API directly using the HTTP scraper. No log forwarding infrastructure needed. - [Logs Scraper](/docs/integrations/azure-ad/audit-logs/logs-scraper.md): If you already forward your Entra ID logs to a log backend (via Azure Monitor Diagnostic Settings), use the Logs scraper to pull them into Mission Control. - [Getting Started](/docs/integrations/azure-ad/getting-started.md): This guide walks you through setting up the Entra ID scraper — from Azure Portal configuration to a working access audit. - [Microsoft Graph API](/docs/integrations/azure-ad/ms-graph.md): When the built-in Entra ID scraper doesn't cover your needs — custom $filter queries, specific user attributes, or endpoints not yet supported — you can use the HTTP scraper with Microsoft Graph API directly. - [Azure DevOps](/docs/integrations/azure-devops.md): Mission Control integrates with Azure DevOps to monitor pipelines and trigger builds. - [Clickhouse](/docs/integrations/clickhouse.md): Mission Control integrates with Clickhouse to scrape configuration data from databases and cloud storage. - [Crossplane Integration](/docs/integrations/crossplane.md): Mission Control integrates with Crossplane to provide visibility into your infrastructure-as-code. Use it to: - [Email / SMTP](/docs/integrations/email.md): Mission Control integrates with SMTP servers to send email notifications. - [Flux](/docs/integrations/flux.md): Mission Control integrates with Flux to provide visibility into your GitOps workflows and automate reconciliation management. - [FluxCD](/docs/integrations/flux/catalog.md): Mission Control provides built-in support for relating Flux resources to each other, determining their health status, and building a dependency graph. This allows you to: - [Flux Playbooks](/docs/integrations/flux/playbooks.md): Mission control enhances a flux deployment with: - [Topology](/docs/integrations/flux/topology.md): The Flux topology provides a comprehensive view of your Flux-based GitOps infrastructure by monitoring and visualizing several key components: - [Google Cloud](/docs/integrations/gcp.md): Mission Control integrates with Google Cloud Platform to provide visibility into your cloud infrastructure. - [GitHub](/docs/integrations/github.md): Mission Control integrates with GitHub to monitor repositories and trigger workflows. - [GitLab](/docs/integrations/gitlab.md): Mission Control integrates with GitLab for GitOps workflows and repository operations. - [Grafana](/docs/integrations/grafana.md): Mission Control integrates with Grafana through its underlying data sources. - [Helm](/docs/integrations/helm.md): Mission Control integrates with Helm to manage chart deployments across clusters. - [HTTP](/docs/integrations/http.md): Mission Control integrates with HTTP endpoints to monitor APIs and web services. - [Kubernetes](/docs/integrations/kubernetes.md): Mission Control provides deep integration with Kubernetes clusters for complete visibility into your containerized infrastructure. - [Getting Started](/docs/integrations/kubernetes/getting-started.md): Mission Control provides comprehensive monitoring and management capabilities for your Kubernetes clusters. It automatically discovers and tracks: - [Playbooks](/docs/integrations/kubernetes/playbooks.md): Self-service playbooks empower teams to manage their Kubernetes resources efficiently: - [Kustomize](/docs/integrations/kustomize.md): Mission Control integrates with Kustomize to simplify configuration management through GitOps-native playbooks. - [LDAP](/docs/integrations/ldap.md): Mission Control integrates with LDAP directories to monitor authentication infrastructure. - [Loki](/docs/integrations/loki.md): Mission Control integrates with Grafana Loki to query and stream logs in playbooks. - [MCP (Model Context Protocol)](/docs/integrations/mcp.md): Mission Control provides an MCP (Model Context Protocol) server that enables AI assistants like Claude to interact with your infrastructure. - [Opensearch](/docs/integrations/opensearch.md): Mission Control integrates with Opensearch and Elasticsearch to monitor your search infrastructure. - [PostgreSQL](/docs/integrations/postgres.md): Mission Control integrates with PostgreSQL to monitor your database infrastructure. - [Prometheus](/docs/integrations/prometheus.md): Mission Control integrates with Prometheus to monitor your metrics infrastructure. - [Slack](/docs/integrations/slack.md): Mission Control integrates with Slack to send notifications and scrape workspace data. - [Slack Bot](/docs/integrations/slack-bot.md): Mission Control Assistant is a Slack bot that responds to direct messages and @mentions. The bot uses Slack Socket Mode, which opens a WebSocket connection so you do not expose a public webhook endpoint. - [SQL Server](/docs/integrations/sql-server.md): Mission Control integrates with Microsoft SQL Server to monitor your database infrastructure. - [Teams](/docs/integrations/teams.md): Mission Control integrates with Microsoft Teams to send notifications to channels. - [Terraform](/docs/integrations/terraform.md): Mission Control integrates with Terraform to provide visibility into your infrastructure-as-code. Use it to: - [Trivy](/docs/integrations/trivy.md): Mission Control integrates with Trivy to scan your Kubernetes clusters for security issues. - [Reference](/docs/reference.md) - [Business Hours](/docs/reference/business_hours.md): Configure and evaluate business hours in CEL expressions and Go templates. - [Canary Checker](/docs/reference/canary-checker.md): | Field | Description | Type | Required | - [Check](/docs/reference/canary-checker/check.md): | Field | Description | Scheme | - [Config DB](/docs/reference/config-db.md) - [Changes](/docs/reference/config-db/changes.md): Fields available during change filtering / mapping - [Config](/docs/reference/config-db/config.md): Fields available during lookup and transformation - [Config Access](/docs/reference/config-db/config_access.md): Config Access tracks who has access to configuration items and their access history. This enables compliance auditing, security monitoring, and periodic access reviews. - [Property](/docs/reference/config-db/properties.md): Property fields for config items - [Scrape Result](/docs/reference/config-db/scrape-result.md): Fields available during scrape transform - [Transformation](/docs/reference/config-db/transformation.md): Schema reference for config-db transformation options - [Connections](/docs/reference/connections.md): Secure credential management for integrating with external systems and services - [Anthropic](/docs/reference/connections/anthropic.md): Connect to Anthropic's Claude API for AI-powered playbook actions and analysis - [AWS](/docs/reference/connections/aws.md): Connect to Amazon Web Services for health checks, config scraping, and playbook actions - [Azure](/docs/reference/connections/azure.md): Connect to Microsoft Azure for health checks, config scraping, and playbook actions - [Azure DevOps](/docs/reference/connections/azure-devops.md): Connect to Azure DevOps for repository access, pipeline automation, and work item management - [Discord](/docs/reference/connections/discord.md): Connect to Discord for sending notifications and alerts via webhooks - [GCP](/docs/reference/connections/gcp.md): Connect to Google Cloud Platform for health checks, config scraping, and playbook actions - [Git](/docs/reference/connections/git.md): Connect to Git repositories for GitOps workflows, configuration management, and playbook actions - [GitHub](/docs/reference/connections/github.md): Connect to GitHub for repository access, issue management, and workflow automation - [GitLab](/docs/reference/connections/gitlab.md): Connect to GitLab for repository access, issue management, and pipeline automation - [HTTP](/docs/reference/connections/http.md): Connect to HTTP/HTTPS endpoints for API integrations, webhooks, and health checks - [KMS](/docs/reference/connections/KMS.md) - [AWS KMS](/docs/reference/connections/KMS/aws-kms.md): Example - [Azure Key Vault](/docs/reference/connections/KMS/azure-key-vault.md): Example - [GCP KMS](/docs/reference/connections/KMS/gcp-kms.md): Example - [Kubernetes](/docs/reference/connections/kubernetes.md): Connect to Kubernetes clusters for health checks, config scraping, and playbook actions - [Notifications](/docs/reference/connections/Notifications.md): Notification connection docs are available under the main Connections section: - [ntfy](/docs/reference/connections/ntfy.md): Connect to ntfy for push notifications to mobile and desktop devices - [Ollama](/docs/reference/connections/ollama.md): Connect to local Ollama instances for self-hosted AI-powered playbook actions - [OpenAI](/docs/reference/connections/openai.md): Connect to OpenAI API for AI-powered playbook actions and analysis - [OpenSearch](/docs/reference/connections/opensearch.md): Connect to OpenSearch clusters for log queries, search operations, and monitoring - [Postgres](/docs/reference/connections/postgres.md): Connect to PostgreSQL databases for health checks, queries, and playbook actions - [Pushbullet](/docs/reference/connections/pushbullet.md): Connect to Pushbullet for push notifications across devices - [Pushover](/docs/reference/connections/pushover.md): Connect to Pushover for push notifications to mobile devices - [SFTP](/docs/reference/connections/sftp.md): Connect to SFTP servers for file transfers and backup monitoring - [Slack](/docs/reference/connections/slack.md): Connect to Slack for sending notifications and alerts - [SMB / CIFS](/docs/reference/connections/smb.md): Connect to Windows file shares for file operations and backup monitoring - [SMTP](/docs/reference/connections/smtp.md): Connect to SMTP servers for sending email notifications - [Telegram](/docs/reference/connections/telegram.md): Connect to Telegram for sending notifications and alerts via bot - [Env Vars](/docs/reference/env-var.md): Mission Control uses the Kubernetes ValuesFrom pattern to retrieve sensitive values like usernames, password and access keys. - [Helm](/docs/reference/helm.md) - [Mission Control](/docs/reference/helm/mission-control.md): { - [Mission Control Agent](/docs/reference/helm/mission-control-agent.md) - [Image Variants](/docs/reference/image-variants.md): Canary checker comes with 2 image variants: - [Logging](/docs/reference/logging.md): Mission Control uses structured logging with named loggers and configurable log levels. Log levels can be set at startup via CLI flags or environment variables, and changed at runtime via the /debug/loggers API or system properties. - [Channels](/docs/reference/notifications.md): Mission control uses Shoutrrr under the hood to deliver notifications. Most of the services in the Shoutrrr are supported. Here's the complete list: - [Template Functions](/docs/reference/notifications/template_functions.md): Special template functions are made available on notifications to complex block formation easier. - [Template Variables](/docs/reference/notifications/template_vars.md) - [Check Events](/docs/reference/notifications/template_vars/checks.md): List of template variables available on check events. - [Config Events](/docs/reference/notifications/template_vars/config.md): Agent - [Permissions](/docs/reference/permissions.md) - [Permission Actions Reference](/docs/reference/permissions/actions.md): Core Actions - [Playbook](/docs/reference/playbooks.md): | Field | Description | Scheme | - [Context](/docs/reference/playbooks/context.md): CEL Expressions - [Env Vars](/docs/reference/playbooks/env-vars.md): Env Vars are variables that can be used to template playbook actions. In the snippet above, you can see an env var auth_token that's pulled in from a kubernetes secret and then used to template the Exec action. - [Event Triggers](/docs/reference/playbooks/events.md): Playbook can be triggered when specific occurs, e.g. you can trigger a playbook to run when a component becomes unhealthy. - [Parameters](/docs/reference/playbooks/parameters.md): Playbook parameter defines a parameter that a playbook needs to run. - [Webhook](/docs/reference/playbooks/webhooks.md): | Field | Description | Scheme | Required | - [RBAC](/docs/reference/rbac.md): Mission control heavily uses RBAC to manage access control and permissions within the system. In our system, we have defined the following roles: - [Resource Selectors](/docs/reference/resource-selector.md) - [Scripting](/docs/reference/scripting.md) - [CEL Expressions](/docs/reference/scripting/cel.md): expr expressions use the Common Expression Language (CEL) - [Go Templates](/docs/reference/scripting/gotemplate.md): template expressions use the Go Text Template library with some additional functions provided by the gomplate library. - [Javascript](/docs/reference/scripting/javascript.md): javascript expressions use to the otto Javascript VM - [Common Types](/docs/reference/types.md) - [Security](/docs/security.md): At Flanksource, security isn't just a feature; it's the foundation of the design that went into the Mission Control platform. We've meticulously designed every aspect of our internal developer platform to meet the stringent requirements of security teams. - [Hardening](/docs/security/hardening.md): Service Account RBAC - [Log Levels](/docs/system-properties.md): Debug and trace settings are different to debug and trace log levels. Log levels are used for general service output - The log volume scales with functionality, not with data. Debug and trace on the otherhand are defined on individual objects e.g. Canaries, Scrapers, Playbooks etc and scale with data volumes. Resource level debug/trace usually have the resource name/id as a prefix