---
# System prepended metadata

title: Capability-based Security Model
tags: [draft]

---

# Capability-based Security Model
**Author**: @aat, @aszlavik, @gak

## Description (what)

The proposed security model allows runners in the FTL cluster to independently verify whether a peer is authorised to access their resources. It is based on PKI, where the control plane signs a set of allowed capabilities for each deployment.

## Motivation (why)

FTL needs a mechanism to ensure that resources within the system are only being accessed by authorised actors. We also need to eventually support direct routing, whereby runners call each other directly rather than proxying through the control plane.

## Goals

- Prevent unauthorised access of FTL resources.
- Provide a flexible authorisation system.

### Non-Goals

- We will not implement mTLS for identity within FTL. We currently assume the underlying platform provides mTLS, though this design does not rely on it.

## Design (how)

- Each Runner will generate a key pair when it is first deployed.
- The Controller will act as a CA.
- The CA public key will be provided to each Runner when it starts up.
- 

```mermaid
---
title: Provisioning a Runner
---
flowchart TB
  Controller -- CreateDeployment(SessionID) --> Provisioner
  Provisioner -- CreateK8SDeployment(SessionID+CAPublicKey) --> Kubernetes
  Runner -- GenerateKeyPair() --> Runner

```

### Required changes (how)

- A short list of changes required to implement the design

## Rejected Alternatives

Other ideas that were considered but rejected, including reasoning.

