AWS Controllers for k8or
By Anna V. April 23, 2025. Version: 0.0.01
Layer 1: The Big Picture
What is this?
In the k8or Orbit platform, infrastructure and application deployment are unified under GitOps principles. AWS Controllers for k8or (ACK) extend this paradigm by enabling Kubernetes-native provisioning of AWS services directly from within Orbit-managed clusters.

These controllers make AWS services — like S3, RDS, DynamoDB, and SNS — manageable using Kubernetes manifests, Git repositories, and Orbit’s continuous delivery systems. This turns cloud infrastructure into versioned, declarative, auditable resources governed by the same pipelines that manage Orbit microservices.
Why it matters
Developers and DevOps teams no longer need to use external tools (Terraform, CloudFormation) to provision cloud infrastructure.
Resources like S3 buckets or RDS databases can be declared as YAML in the same Git repo as the application that uses them.
Orbit environments (dev/test/prod) can be dynamically provisioned and consistently managed across all clusters with zero manual AWS console interaction.
Layer 2: k8or-Specific Integration Overview
How it works in k8or Orbit
ACK introduces CRDs (Custom Resource Definitions) for AWS services and pairs each CRD with a controller that syncs the desired state to AWS via API calls.
In the Orbit ecosystem, each controller:
Runs in a K3s cluster under Orbit management.
Authenticates through IRSA (IAM Roles for Service Accounts) to ensure scoped access per environment.
Receives configuration via Argo CD (C108), syncing with manifests generated or stored in GitLab (C100) or ChartStore (C20).
Operates under the security perimeter of AccessPoint (C52) to control and log API interactions.
Orbit-Aware Features
Cluster Bootstrapping
ACK manifests are deployed during post-creation setup.
Continuous Delivery
Managed via Argo CD ApplicationSets.
Environment Isolation
IAM roles and CRDs are namespace-scoped by Orbit env.
Audit & Security
All ACK activity is logged via AccessPoint and ViewPort.
Common Use Cases in Orbit
Provisioning S3 buckets for manifest uploads in dev clusters.
Creating DynamoDB tables for feature-flag metadata in test clusters.
Managing RDS instances for production-grade applications, per cluster.
Layer 3: Internal Architecture & Control Flow
System Components
Custom Resource Definitions (CRDs)
Define AWS services in YAML (e.g.,
kind: Bucket
,kind: DBInstance
).Stored in Git and version-controlled per application/environment.
ACK Controllers
Watch for CRD creation/updates and perform reconciliation.
Use the AWS Go SDK and REST APIs to reflect desired state.
IAM Roles for Service Accounts (IRSA)
Each controller authenticates using an IAM role mapped to a Kubernetes service account.
Role boundaries are enforced at the environment or namespace level.
Argo CD + ApplicationSets
Detects changes to CRDs and deploys them across one or many clusters.
Provides status updates and rollback capabilities.
AccessPoint Security Gateway
Routes all outbound ACK API calls.
Logs, audits, and enforces token-based RBAC before allowing resource modification.
Control Flow in Orbit
A developer commits a new manifest (e.g.,
s3-bucket.yaml
) to GitLab (C100).Argo CD (C108) detects the change and applies it to the appropriate Orbit cluster.
The ACK S3 controller sees the CRD and issues an AWS API request to create the bucket.
AccessPoint (C52) validates and forwards the request.
Status is synced back to the CRD (
status.conditions
) and reflected in the Portal (C8).
Layer 4: Configuration Examples and Code-Level Implementation
Example: Provisioning an S3 Bucket
apiVersion: s3.services.k8s.aws/v1alpha1
kind: Bucket
metadata:
name: airchina-app-storage
namespace: airchina-dev-env
spec:
name: airchina-app-storage-{{ .Environment }}
This file lives in the Orbit GitLab repo alongside application manifests.
Example: Argo CD ApplicationSet for ACK
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: k8or-aws-bucket-policy
spec:
generators:
- list:
elements:
- cluster: dev-airchina
path: manifests/dev/aws
template:
metadata:
name: '{{cluster}}-s3-bucket'
spec:
project: default
source:
repoURL: https://gitlab.k8or.com/app-repo.git
targetRevision: HEAD
path: '{{path}}'
destination:
server: '{{cluster}}'
namespace: airchina-dev-env
syncPolicy:
automated:
prune: true
selfHeal: true
IAM Role Mapping (IRSA)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:CreateBucket", "s3:PutBucketPolicy", "s3:DeleteBucket"],
"Resource": "*"
}
]
}
This policy is attached to the Kubernetes service account used by the ack-s3-controller
.
✅ Benefits Recap
Unified GitOps Management
Infrastructure and applications are deployed together.
Environment-Specific Provisioning
Dynamic per-cluster setups with no manual AWS ops.
Security via AccessPoint
Centralized RBAC + audit for all AWS provisioning.
Rapid Cluster Bootstrap
RDS, S3, and other infra can be provisioned in seconds.
Scalable to Multiple Clusters
ACK works across all dev/test/prod clusters via Argo.
Last updated