Security

Planton is a DevOps platform that touches some of the most sensitive parts of your infrastructure: cloud credentials, deployment secrets, production access controls, and runtime operations. The security model is designed around one premise — you should not have to trust Planton with more than you want to give it.

This page is an overview of how security works across the platform. Each section links to the detailed documentation where the full implementation is described.

Credential Isolation

The defining security property of Planton is that your cloud credentials do not need to leave your infrastructure.

When Planton needs to interact with your cloud provider — creating a VPC, deploying a container, querying a database — it sends the instruction through a secure tunnel to a Runner deployed in your environment. The Runner executes the operation using credentials it holds locally. Planton's control plane never receives, stores, or transmits your cloud credentials in plaintext.

This is not encryption at rest (though that exists too). It is architectural isolation. The credentials physically stay in your infrastructure. A breach of Planton's control plane does not expose your cloud credentials, because Planton does not have them.

Three authentication modes give you control over the security posture of each connection:

• Inline credentials — You provide credentials to Planton (encrypted at rest). Simplest to set up, suitable for development environments.
• Runner-delegated authentication — The Runner uses its own cloud identity (IRSA, Workload Identity, Managed Identity). No credential material is stored anywhere. The strongest isolation.
• Cross-account trust — The Runner uses AWS STS AssumeRole to access resources across AWS accounts. No long-lived credentials are exchanged.

For full details, see Runner Security Model and Connections: Cloud Providers.

Encryption

Data at Rest

Every secret stored in Planton's Secrets Manager is protected by envelope encryption — the same pattern used by AWS KMS, GCP Cloud KMS, and Azure Key Vault for their own services.

Each secret version gets a unique AES-256 data encryption key (DEK). That DEK is encrypted by a key encryption key (KEK) before being stored alongside the ciphertext. Even with direct access to the storage backend, an attacker sees only encrypted data and an encrypted key.

By default, Planton manages the KEK. Organizations that require cryptographic control can bring their own key from AWS KMS, GCP Cloud KMS, or Azure Key Vault — Customer-Managed Encryption Keys (CMEK). Revoking a CMEK renders all encrypted secrets permanently unreadable, including by Planton.

There is no option to disable encryption. You choose who controls the key, not whether encryption happens.

For full details, see Secret Backends and Encryption.

Data in Transit

All communication between the Runner and Planton's control plane is protected by mutual TLS (mTLS). Both sides present certificates and verify each other's identity. The Runner's certificate is bound to its organization, meaning the control plane cryptographically validates that a Runner belongs to the organization it claims before accepting any connection.

All web console and API traffic uses standard TLS encryption.

Authentication

Planton supports three authentication methods for users and automation:

Interactive login — Users authenticate through an OAuth identity provider using the PKCE flow (no client secrets). The web console handles this automatically. The CLI initiates a browser-based login:

planton auth login

API keys — For CI/CD pipelines, scripts, and automation that cannot use a browser. API keys are scoped to the user who created them and carry that user's permissions. Keys are stored as hashes — Planton never persists the plaintext key after creation. Keys support expiration dates and track last-used timestamps.

planton iam apikey new --name "ci-pipeline"

Service accounts — For machine-to-machine authentication. Service accounts are dedicated machine identities with their own API keys, purpose-built for Runners and other automated systems. When you generate credentials for a runner, Planton auto-provisions a service account and mints an API key — the runner uses it to authenticate with the control plane and resolve secrets at runtime.

planton sa create --org acme --name deploy-runner

For full details on roles and permissions, see Authentication and Authorization.

Authorization

Planton uses OpenFGA — an open-source, fine-grained authorization engine — for all access control decisions. This is not a simple role list. It is a relationship-based authorization model where permissions flow through the resource hierarchy.

The key properties:

• Hierarchical inheritance — Grant a user admin access to an organization, and they automatically have admin access to every environment and resource within it. No need to assign permissions at each level individually.
• Resource-scoped roles — Roles are specific to resource types. An "admin" on an organization is different from an "admin" on a service. Five standard roles apply across most resources: owner, admin, IAM admin, viewer, and member.
• Team-based access — Permissions granted to a team flow to all team members, including nested teams. Add someone to the Platform Engineering team, and they inherit every permission that team holds.
• Environment authorization for credentials — Connections must be explicitly authorized for each environment before they can be used there. A production AWS credential cannot be accidentally used in development.

For the full authorization model, see Authentication and Authorization.

Audit Trails

Every resource change in Planton is captured as an immutable version record. The audit system records:

• Full state snapshots — The complete YAML representation of the resource before and after the change
• Unified diffs — Git-style diffs showing exactly what changed
• Who and when — The identity account that made the change and the timestamp
• Event type — Whether the resource was created, updated, deleted, or restored
• Deployment linkage — For infrastructure changes, the version links to the Stack Job that executed the deployment, including whether it succeeded or failed

Version records are append-only and immutable. They form a linked chain — you can walk backward through any resource's complete history.

The web console provides a versions list, full version detail view, and side-by-side diff visualization. Access to audit data is authorization-gated — you can only view versions for resources you have permission to see.

For full details, see Audit Trails.

Network Security

The Runner's network model eliminates the need for inbound firewall rules, VPN tunnels, or network peering:

• Outbound-only connectivity — The Runner initiates all connections. It connects outbound to Planton's control plane over HTTPS (port 443). No inbound ports need to be opened.
• No VPN required — The secure tunnel is established over standard HTTPS, which passes through corporate firewalls and proxies without special configuration.
• mTLS authentication — Both the Runner and the control plane verify each other's identity with every connection. Man-in-the-middle attacks require compromising the CA private key.
• Organization-scoped identity — Each Runner's cryptographic identity is bound to its organization. A Runner registered to Organization A cannot receive requests intended for Organization B.

Platform Security Summary

Related Documentation

• Authentication and Authorization — How users authenticate and how permissions are evaluated
• Audit Trails — Immutable change tracking and version history
• Runner Security Model — Credential isolation, mTLS, and authentication modes
• Secrets — Envelope encryption, CMEK, and secret backends
• Connections — Credential management and environment authorization
• Teams and Access — Membership, teams, and role-based access