Connections

Connections provide a secure, reusable way to authenticate against external systems and services. Instead of embedding credentials directly in your health checks, scrapers, and playbooks, you define connections once and reference them throughout your configuration.

Benefits

• Security: Credentials are stored securely in Kubernetes secrets, not in plain text
• Reuse: Define once, use across multiple resources
• Maintainability: Update credentials in one place when they change
• Auditability: Track which resources use which connections

Connection Types

Category	Connections
Cloud Providers	AWS, Azure, GCP
Key Management	KMS, AWS KMS, Azure Key Vault, GCP KMS
Kubernetes	Kubernetes
Source Control	Git, GitHub, GitLab, Azure DevOps
Databases	Postgres, OpenSearch
File Storage	SFTP, SMB
AI Providers	OpenAI, Anthropic, Ollama
Notifications	Slack, Discord, Telegram, SMTP, Ntfy, Pushbullet, Pushover
Generic	HTTP

Creating Connections

Connections can be created via Kubernetes CRD or through the Mission Control UI.

Kubernetes CRD

connection-example.yaml
apiVersion: mission-control.flanksource.com/v1
kind: Connection
metadata:
  name: payments-database
  namespace: default
spec:
  postgres:
    host:
      value: postgres.example.com
    database:
      value: payments
    username:
      valueFrom:
        secretKeyRef:
          name: postgres-credentials
          key: POSTGRES_USER
    password:
      valueFrom:
        secretKeyRef:
          name: postgres-credentials
          key: POSTGRES_PASSWORD

UI Configuration

Connections can also be created through the Settings page in the Mission Control UI. This is useful for quick setup and for users who prefer a visual interface.

Referencing Connections

Once created, connections can be referenced using the connection:// URL scheme:

connection://[namespace]/[connection-name]

Example Usage

canary-with-connection.yaml
apiVersion: canaries.flanksource.com/v1
kind: Canary
metadata:
  name: postgres-check
spec:
  postgres:
    - name: Database Health Check
      connection: connection://default/payments-database
      query: SELECT 1

tip

The connection string can be found in the status.ref field of the Connection Kubernetes object.

Credential Sources

Connection fields support multiple ways to specify values:

Direct Value

host:
  value: postgres.example.com

From Kubernetes Secret

password:
  valueFrom:
    secretKeyRef:
      name: my-secret
      key: password

From ConfigMap

host:
  valueFrom:
    configMapKeyRef:
      name: my-config
      key: database-host

From Helm Values

password:
  valueFrom:
    helmRef:
      name: my-release
      key: database.password

URL Template Pattern

For connections where all credentials are embedded in a URL, you can use variable substitution:

connection-url-template.yaml
apiVersion: mission-control.flanksource.com/v1
kind: Connection
metadata:
  name: opensearch-global
spec:
  type: opensearch
  url:
    value: "https://$(username):$(password)@opensearch.example.com:9200"
  username:
    valueFrom:
      secretKeyRef:
        name: opensearch-credentials
        key: OPENSEARCH_USER
  password:
    valueFrom:
      secretKeyRef:
        name: opensearch-credentials
        key: OPENSEARCH_PASSWORD

tip

If the entire URL is stored in a secret, you can fetch it directly:

kind: Connection
metadata:
  name: opensearch-from-url
spec:
  type: opensearch
  url:
    value: $(password)
  password:
    valueFrom:
      secretKeyRef:
        name: opensearch-credentials
        key: OPENSEARCH_URL

Schema

Field	Description	Scheme	Required
url	URL in templatable form	EnvVar
port	Port number	EnvVar
type	Type of datasource (postgres, mysql, etc.)	string
username	Username for authentication	EnvVar
password	Password for authentication	EnvVar
certificate	Certificate for verification	EnvVar
properties	Additional property fields	map[string]string
insecure_tls	Skip TLS certificate verification	bool

Permissions

Reading a connection and using it are different actions:

• read lets a subject list and open a connection, without its credentials, which are always masked.
• connection:use lets a subject act with its credentials: a notification sending through it, a playbook or plugin calling it, or a test of the connection.

Mission Control checks connection:use as the subject doing the work, such as the playbook or notification, not the person who started it. This manifest lets the mc/http-authorized playbook use the mc/httpbin connection:

connection-permission.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

See Seeing a connection versus using it.