Cloud Providers

To deploy infrastructure through Planton, the platform needs permission to act in your cloud accounts. Cloud provider connections give Planton the credentials it needs to create, update, and manage resources — from VPCs and Kubernetes clusters to databases and DNS zones — while keeping those credentials encrypted and scoped to the environments you authorize.

Choosing an Authentication Mode

Every cloud provider connection starts with a choice: how should Planton authenticate?

Inline Credentials

Provide your access keys or service account credentials directly. Planton encrypts them at rest and injects them at deployment time. This is the fastest way to get started.

When to use: Development environments, proof of concept, small teams where simplicity outweighs the operational overhead of managing a Runner.

Trade-off: The credentials are stored (encrypted) in Planton's control plane. For organizations with strict policies about where credentials can reside, consider runner-delegated authentication instead.

Runner-Delegated Authentication

Deploy a Planton Runner in your own infrastructure and let it authenticate using the cloud environment's native identity system — AWS IRSA, GCP Workload Identity, or Azure Managed Identity. No credentials are stored in Planton's control plane. The Runner authenticates locally and executes deployments where the credentials already exist.

When to use: Production environments, compliance-sensitive workloads, organizations that require credentials to never leave their network perimeter.

Trade-off: Requires deploying and maintaining a Runner. See the Runner documentation for deployment options.

Cross-Account Trust (AWS Only)

Create an IAM role in your AWS account that trusts Planton's Runner. When a deployment runs, the Runner assumes that role using AWS STS — no long-lived access keys are exchanged. This approach combines the convenience of not managing inline keys with the security of role-based access.

When to use: AWS organizations with multi-account strategies, teams that follow AWS best practices for cross-account access.

Trade-off: Requires initial IAM role setup (automated via CloudFormation Quick Create) and a Runner for execution.

AWS

AWS is the most fully featured cloud provider integration. It supports all three authentication modes and includes an automated setup flow using AWS CloudFormation.

Connecting via the Web Console

1. Navigate to Connections and click the AWS card under Infrastructure.
2. Name your connection — choose a descriptive name like "aws-production" or "aws-dev-sandbox". The slug is auto-generated.
3. Choose your authentication method:
   • Inline API Keys — Enter your Access Key ID and Secret Access Key directly.
   • Cross-Account Trust — Planton generates a CloudFormation Quick Create link. Click it to open the AWS Console, review the stack, and create the IAM role. The role ARN is captured automatically.
   • Self-Hosted Runner — Select an existing Runner or create a new one. The Runner handles authentication using its environment credentials.
4. Create the connection.

Connecting via the CLI

The CLI provides a browser-based CloudFormation flow for AWS:

# Interactive setup — opens browser for CloudFormation Quick Create
planton connect aws

# Specify details upfront
planton connect aws --name my-aws-prod --account-id 123456789012

# Select specific capabilities
planton connect aws --capabilities eks,vpc_networking,s3_storage

# Reconnect an existing credential with a new IAM role
planton connect aws --reconnect my-aws-prod

AWS Capabilities

When connecting via CloudFormation, you can scope the IAM role to specific capabilities. This follows the principle of least privilege — grant only the permissions Planton needs for the resource types you plan to deploy.

Available capabilities: EKS, ECS, VPC networking, S3 storage, RDS databases, Lambda compute, Route 53 DNS, CloudWatch monitoring, ECR container registry, KMS encryption.

By default, all capabilities are granted. You can narrow the scope during initial setup or when reconnecting.

What You Need

For cross-account trust, the CloudFormation stack handles IAM role creation automatically. For runner-delegated auth, you need a Runner deployed with appropriate IAM permissions.

Google Cloud Platform

GCP connections use a service account key to authenticate. Planton acts as the service account when creating and managing resources in your GCP project.

Connecting via the Web Console

1. Navigate to Connections and click the GCP card under Infrastructure.
2. Name your connection and provide the service account key JSON file (base64-encoded).
3. Create the connection.

What You Need

Preparing Your GCP Service Account

In the Google Cloud Console:

1. Create a service account in the project where Planton will manage resources.
2. Grant the service account the IAM roles needed for your resource types (e.g., Kubernetes Engine Admin for GKE clusters, Cloud SQL Admin for databases).
3. Create a JSON key for the service account.
4. Base64-encode the key file for use in Planton.

GCP connections support both inline and runner-delegated authentication. For runner-delegated auth, deploy a Runner with GCP Workload Identity configured.

Microsoft Azure

Azure connections use a service principal (app registration) to authenticate. Planton acts as the service principal when managing resources in your Azure subscription.

Connecting via the Web Console

1. Navigate to Connections and click the Azure card under Infrastructure.
2. Name your connection and provide the service principal credentials.
3. Create the connection.

What You Need

Preparing Your Azure Service Principal

In the Azure Portal:

1. Register an application in Azure Active Directory.
2. Create a client secret for the application.
3. Assign the application the Contributor role (or more restrictive custom roles) on the subscription or resource groups where Planton will manage resources.

Azure connections support both inline and runner-delegated authentication. For runner-delegated auth, deploy a Runner with Azure Managed Identity configured.

DigitalOcean

DigitalOcean connections use an API token to authenticate. Optionally, you can provide Spaces credentials for object storage operations.

What You Need

Generate an API token from the DigitalOcean control panel under API > Tokens/Keys. For Spaces, create a separate Spaces access key under API > Spaces Keys.

Civo

Civo connections use an API token. Optionally, you can provide object store credentials.

What You Need

Generate an API token from the Civo dashboard under Settings > Profile > Security.

Cloudflare

Cloudflare connections support two authentication schemes. The recommended approach uses a scoped API token; the legacy approach uses a global API key with your account email.

What You Need (Recommended)

What You Need (Legacy)

R2 Storage Credentials

If you deploy Cloudflare Workers that use R2 storage, you also need R2 credentials:

Create API tokens in the Cloudflare dashboard under My Profile > API Tokens. Use the Create Token button to create a scoped token with only the permissions your deployments need.

Common Patterns

One Connection Per Account

Create separate connections for each cloud account. A "production AWS account" and a "development AWS account" should be two distinct connections, even if they belong to the same organization. This makes it straightforward to authorize the right credential for the right environment.

Naming Conventions

Use names that identify both the provider and the purpose:

• aws-production — clear and specific
• gcp-analytics-project — identifies the GCP project's role
• azure-staging — identifies the environment intent

Avoid generic names like aws1 or my-cloud — they become confusing as the number of connections grows.

Credential Rotation

To rotate credentials, update the connection with new values. Planton uses the updated credentials for all future deployments. In-flight deployments continue with the credentials they started with. No downtime is required.

For AWS cross-account trust connections, rotation means updating the IAM role — use the --reconnect flag in the CLI to set up a new role.

Related Documentation

• Connections Overview — Understanding the Connect system
• Environment Mappings — Authorize connections for specific environments
• Default Connections — Configure automatic credential selection
• Runner — Deploy a Runner for runner-delegated authentication