Introducing Cordium — Identity-based Sandboxes for Developers & AI Agents

AWS access

Zero trust access to your AWS resources

Octelium is a free and open source, self-hosted zero trust access platform. It reaches private VPC resources across accounts and regions, RDS databases, EKS clusters, S3 buckets and Lambda function URLs through one identity model, with the AWS credential held by the Cluster rather than distributed to people and jobs.

Install in minutes GitHub repo

Free and open source
Designed for self-hosting
SigV4 signing at the proxy

s3.yaml

An S3 bucketThe SigV4 credential stays in the Cluster and signs the request on the User's behalf.

An S3 bucket. The SigV4 credential stays in the Cluster and signs the request on the User's behalf.

kind: Service
metadata:
  name: s3
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: https://bucket.s3.eu-central-1.amazonaws.com
    http:
      auth:
        sigv4:
          accessKeyID: AKIA...
          secretAccessKey:
            fromSecret: s3-bucket-1
          region: eu-central-1
          service: s3

A Policy. Access is authorized per request, from identity, context and the request itself.

kind: Policy
metadata:
  name: s3-read-only
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.http.method == "GET"
            - match: '"analysts" in ctx.user.spec.groups'

An RDS database. The database password stays in the Cluster, and the Service forces the database user.

kind: Service
metadata:
  name: rds-prod
spec:
  mode: POSTGRES
  port: 5432
  config:
    upstream:
      url: postgres://db.abc.eu-central-1.rds.amazonaws.com
    postgres:
      user: analytics_ro
      database: analytics
      auth:
        password:
          fromSecret: rds-password
      sslMode: REQUIRE

The platform

A unified secure access platform

Secure humans, workloads and AI agents with one model for identity, authorization, connectivity, credentials and visibility.

Client-based and clientless

One architecture across accounts and regions

Each resource is protected by an identity-aware proxy that provides application-layer-aware access control, secretless access, and visibility. Which VPC, account or region an upstream sits in becomes a detail of the Service definition.

Read how Octelium works

service-vpc.yaml

A private VPC resourceAn internal service in a VPC, reached over the tunnel through a single stable route.

A private VPC resource. An internal service in a VPC, reached over the tunnel through a single stable route.

kind: Service
metadata:
  name: internal-api
spec:
  mode: HTTP
  config:
    upstream:
      url: http://10.0.6.40:8080

Another region, no new route. The upstream is resolved from the side of a connected host inside that VPC.

kind: Service
metadata:
  name: api-us-east
spec:
  mode: HTTP
  config:
    upstream:
      url: http://10.40.2.11:8080
      user: vpc-us-east

An EKS cluster. One kubeconfig lives in the Cluster and is never handed to a User.

kind: Service
metadata:
  name: eks-prod
spec:
  mode: KUBERNETES
  isPublic: true
  config:
    upstream:
      url: https://abc.eks.amazonaws.com
    kubernetes:
      kubeconfig:
        fromSecret: kubeconfig-eks

Access control

Layer-7 aware access control with policy-as-code

Access is authorized on a per-request basis, using CEL or Open Policy Agent, against the identity behind the request and the content of the request itself rather than the security group or subnet it arrived from.

Read about Policies and access control

policy-http.yaml

The request itselfMethod, path, headers and serialized JSON body are all part of the request context.

The request itself. Method, path, headers and serialized JSON body are all part of the request context.

kind: Policy
metadata:
  name: bucket-prefix
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.http.method == "GET"
            - match: ctx.request.http.path.startsWith("/reports/")
            - match: '"analysts" in ctx.user.spec.groups'

Kubernetes verbs. EKS requests are authorized per verb, resource and namespace without sharing a kubeconfig.

kind: Policy
metadata:
  name: eks-sre
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.request.kubernetes.verb in ["get", "list"]
            - match: ctx.request.kubernetes.namespace == "production"
            - match: '"sre" in ctx.user.spec.groups'

Identity and context. Device posture, session type and group membership are attributes like any other.

kind: Policy
metadata:
  name: production
spec:
  rules:
    - effect: ALLOW
      condition:
        all:
          of:
            - match: ctx.user.spec.type == "HUMAN"
            - match: ctx.session.status.type == "CLIENT"
            - match: ctx.device.status.osType in ["MAC", "LINUX"]

Secretless access

AWS credentials that are never distributed

Application-layer credentials are stored in the Cluster as Secrets and used to authenticate upstream once a request is authorized. For AWS that includes signing requests with Signature Version 4 on the caller's behalf.

Read the secretless access guide

lambda.yaml

A Lambda function URLSigV4 signing happens at the proxy, so no IAM key reaches the caller.

A Lambda function URL. SigV4 signing happens at the proxy, so no IAM key reaches the caller.

kind: Service
metadata:
  name: my-lambda
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: https://abc.lambda-url.eu-central-1.on.aws
    http:
      auth:
        sigv4:
          accessKeyID: AKIA...
          secretAccessKey:
            fromSecret: lambda-1
          region: eu-central-1
          service: lambda

An RDS database. The upstream password stays in the Cluster, and the Service forces the database user.

kind: Service
metadata:
  name: rds-prod
spec:
  mode: POSTGRES
  port: 5432
  config:
    upstream:
      url: postgres://db.abc.eu-central-1.rds.amazonaws.com
    postgres:
      user: analytics_ro
      database: analytics
      auth:
        password:
          fromSecret: rds-password

A different account per identity. Identity and request context select which upstream and which credential are used.

kind: Service
metadata:
  name: s3
spec:
  mode: HTTP
  isPublic: true
  config:
    upstream:
      url: https://staging.s3.eu-central-1.amazonaws.com
  dynamicConfig:
    configs:
      - name: prod
        upstream:
          url: https://prod.s3.eu-central-1.amazonaws.com
        http:
          auth:
            sigv4:
              accessKeyID: AKIA...
              secretAccessKey:
                fromSecret: s3-prod
              region: eu-central-1
              service: s3
    rules:
      - condition:
          match: '"sre" in ctx.user.spec.groups'
        configName: prod

Humans, workloads and AI agents

A unified identity model for humans and workloads

Human and workload Users share the same identity management, authentication, access control and visibility model. An ETL job reaching a bucket is authorized and audited exactly as an engineer would be.

Read about Users and identity

idp.yaml

Secretless workload identityWorkloads authenticate with OIDC assertions issued by the platform running them.

Secretless workload identity. Workloads authenticate with OIDC assertions issued by the platform running them.

kind: IdentityProvider
metadata:
  name: github-actions
spec:
  oidcIdentityToken:
    issuerURL: https://token.actions.githubusercontent.com
    audience: https://example.com

An EKS service account. A cluster that publishes its OIDC issuer can authenticate its own workloads.

kind: IdentityProvider
metadata:
  name: eks-prod
spec:
  oidcIdentityToken:
    issuerURL: https://oidc.eks.eu-central-1.amazonaws.com
    audience: https://example.com

A workload User. A job reaching S3 or RDS is a User with its own groups, Policies and audit trail.

kind: User
metadata:
  name: etl-job
spec:
  type: WORKLOAD
  groups:
    - data

Visibility and auditing

Real-time visibility at the application layer

OpenTelemetry-ready, application-layer aware, structured auditing and visibility emitted to your OpenTelemetry OTLP receivers, where they can be exported to your log management and SIEM tools.

Application-layer detail includes HTTP requests and responses, database queries, Kubernetes verbs and resources, SSH session recordings, and MCP and LLM operations.
Because the request is attributed to an Octelium User rather than to a shared IAM identity, an audit shows which person or job made a call rather than which key was used.
Logs are exported over OpenTelemetry OTLP in real-time to SIEM providers you already operate.

Read about visibility and auditing

AccessLogOTLP

ALLOWlinus@acme.compg-prod.dbPOSTGRESquery: select id, email from users limit 50

ALLOWci-runnerprod-k8sKUBERNETESverb=list resource=pods namespace=production

DENYagent-07tools-mcpMCPtools/call name=transfer policy=mcp-tools

ALLOWjane@acme.combastionSSHsession recorded, upstream user=deploy

ALLOWagent-07openaiLLMCHAT_COMPLETIONS model=gpt-5-mini tokens=1284

Deployment and scale

A scalable platform that also deploys your workloads

A Cluster runs on Kubernetes and uses it to scale its own data plane, place Service proxies across Gateways, and run containerized applications that the Cluster itself deploys.

Read the management guide

octeliumctl

❯octeliumctl apply ./cluster

$ octeliumctl apply ./cluster
Secret: s3-bucket-1 Updated
Secret: rds-password Updated
IdentityProvider: eks-prod Created
Policy: s3-read-only Created
Group: analysts Created
Group: sre Updated
Service: s3.aws Created
Service: my-lambda.aws Created
Service: rds-prod.db Created
Namespace: aws Created
Cluster Core resources successfully applied
 7 resources created
 3 resources updated

 ClusterConfig updated

Coverage

What a team reaches in an AWS account, and how

Access to AWS is rarely one problem. These are the kinds of resource that come up, next to the mechanism in an Octelium Cluster that reaches each one.

01
Private resources inside a VPC
An internal service, an EC2 instance or an internal load balancer becomes a Service with a stable private name, reached over the tunnel. Nothing is exposed publicly and no bastion has to be kept running for people to hop through.
Read more
02
Resources in another VPC or region
A Service upstream can be an address that is only reachable from the side of a connected host inside that VPC, which serves it over its own outbound tunnel. Accounts, regions and peering arrangements stop being something the person connecting has to know about.
Read more
03
RDS PostgreSQL and MySQL
The database password is held as a Secret and injected after authorization, and the Service can force the upstream database user and database regardless of what the client asks for. Queries are recorded with the identity that ran them.
Read more
04
S3 buckets
The HTTP mode signs requests upstream with AWS Signature Version 4 using an access key held in the Cluster, so a team or a workload reads a bucket over an ordinary HTTPS client without holding an IAM key.
Read more
05
Lambda function URLs
The same SigV4 mechanism covers Lambda function URLs, with the service field set to lambda, so an invocation is authorized per request against identity and the HTTP request itself.
Read more
06
EKS clusters
The Kubernetes mode holds the kubeconfig, client certificate or bearer token and authorizes each API request by verb, resource, namespace, API group and name, so nobody needs a kubeconfig of their own.
Read more
07
Other AWS APIs
SigV4 signing takes the region and service name as configuration, so the same pattern extends to other AWS APIs that a team or an application needs to call without an IAM identity of its own.
Read more
08
Workloads that run inside AWS
An EKS cluster or a CI system that publishes an OpenID Connect issuer can authenticate its own workloads to the Cluster with federated assertions, so no long-lived credential has to be stored alongside the job.
Read more

IAM still decides what the Cluster's own credential may do. What changes is that the credential stays in one place, and the decision about who may use it is made per request against an identity you already manage.

On every Octelium Cluster

The same platform capabilities ship with every deployment, whichever way you use it.

Questions

Frequently asked

Does this replace IAM?: No. IAM still governs what the credential held by the Cluster is allowed to do inside AWS. What changes is who holds that credential: it stays in the Cluster and is used to sign or authenticate the upstream request after Octelium has authenticated and authorized the caller, so individual people and jobs do not each need an IAM identity and a key on disk.
How does secretless access to S3 and Lambda work?: The HTTP mode supports AWS Signature Version 4 as an upstream authentication method. An access key ID, a secret access key held as a Secret, a region and a service name are configured on the Service, and the proxy signs each authorized request upstream. Callers use an ordinary HTTPS client and their own Octelium credential.
Can it reach resources in several accounts and regions?: Yes. A Service upstream can be an address that is only reachable from the side of a connected host inside that network, which serves it over its own outbound tunnel, so a VPC in another account or region needs no peering, no transit gateway change and no inbound port. Each resource is still reached through a single stable route on the client.
Does the Cluster have to run inside AWS?: No. An Octelium Cluster runs on any Kubernetes, managed or on-premise, including EKS. The quick installer provisions a complete single-node Cluster, including Kubernetes itself, on one fresh Linux VM with 2 vCPUs, 2 GB of RAM and a domain you own, which is enough for evaluation.
How do workloads inside AWS authenticate?: Workload Users can authenticate with authentication tokens, the OAuth2 client credentials flow, or secretlessly with federated OpenID Connect assertions issued by the platform hosting them, including an EKS cluster that publishes an OIDC issuer and CI systems such as GitHub Actions. No special SDK or client is required.
Is Octelium free and open source?: Yes. Octelium is free and open source and is designed for single-tenant self-hosting. There is no proprietary cloud-based control plane, and it is not a limited edition of a separate paid product. An enterprise package is available for organizations that need capabilities such as a web console, SCIM provisioning and secret encryption at rest, and it is free for personal, homelab and evaluation use.

Keep reading

Deploy Octelium on your own infrastructure in minutes

Free and open source. Self-hosted. No vendor lock-in.

Quick install guide GitHub repo Enterprise package

Zero trust access to your AWS resources

A unified secure access platform

One architecture across accounts and regions

Layer-7 aware access control with policy-as-code

AWS credentials that are never distributed

A unified identity model for humans and workloads

Real-time visibility at the application layer

A scalable platform that also deploys your workloads

What a team reaches in an AWS account, and how

Private resources inside a VPC

Resources in another VPC or region

RDS PostgreSQL and MySQL

S3 buckets

Lambda function URLs

EKS clusters

Other AWS APIs

Workloads that run inside AWS

Frequently asked

Related solutions

Zero trust database access

Zero trust Kubernetes access

Zero trust SaaS and API access

Deploy Octelium on your own infrastructure in minutes