How to Provision S3 Buckets in Kubernetes with COSI and VersityGW

Byeonghoon Yoo — Fri, 20 Mar 2026 15:05:02 +0000

Kubernetes has had CSI for block and file storage for years. But if your app needs an S3 bucket, you're on your own — script some API calls, create an IAM user, write a bucket policy, inject the credentials. COSI changes that.

What is COSI?

COSI (Container Object Storage Interface) is a SIG-Storage project that adds two CRDs to Kubernetes:

BucketClaim — like a PersistentVolumeClaim, but for S3 buckets. Apply one and the driver creates the bucket on your storage backend.
BucketAccess — provisions a dedicated IAM user with a scoped bucket policy. The credentials are written to a Kubernetes Secret your app can mount.

Delete the CRs and the bucket, user, and policy get cleaned up. The spec is at v1alpha1 — functional, but expect changes.

What is VersityGW?

VersityGW is an open-source (Apache 2.0) S3-compatible gateway written in Go. Its POSIX backend takes a directory and exposes it as an S3 endpoint — no erasure coding or custom data format. If you have a filesystem (local disk, NFS, ZFS), VersityGW can serve it as S3.

This makes it a good fit for homelabs and on-prem setups where you already have storage and just need an S3 API in front of it.

Architecture

BucketClaim / BucketAccess
        │
        ▼
  COSI Controller
        │
        ▼
    COSI Sidecar
        │ gRPC (Unix Socket)
        ▼
  versitygw-cosi-driver
        │
   ┌────┴────┐
   ▼         ▼
S3 API   Admin API
   └────┬────┘
        ▼
    VersityGW
        │
        ▼
   Filesystem

The driver runs as a Deployment with two containers: the driver itself and the standard COSI sidecar. The sidecar watches Kubernetes CRs and dispatches gRPC calls to the driver over a shared Unix socket.

Prerequisites

A Kubernetes cluster (1.25+, when COSI was introduced)
Helm 3.x
A running VersityGW instance with IAM and Admin API enabled
kubectl configured

Step 1: Install the COSI Controller

The COSI controller manages the CRD lifecycle. Install it with:

kubectl create -k 'https://github.com/kubernetes-sigs/container-object-storage-interface//?ref=v0.2.2'

Verify it's running:

kubectl get pods -A | grep objectstorage

Step 2: Install VersityGW (if not already running)

If you're already running VersityGW, skip this. Otherwise, install it with its Helm chart:

helm install versitygw oci://ghcr.io/versity/versitygw/charts/versitygw \
  --set auth.accessKey=admin \
  --set auth.secretKey=admin123 \
  --set admin.enabled=true \
  --set gateway.iam.enabled=true

The chart creates a credentials Secret automatically (versitygw-versitygw-credentials).

Step 3: Install the COSI Driver

helm install versitygw-cosi-driver \
  oci://ghcr.io/isac322/charts/versitygw-cosi-driver \
  --set driver.name=versitygw.cosi.dev \
  --set versitygw.credentials.secretName=versitygw-versitygw-credentials

This deploys the driver and creates a default BucketClass and BucketAccessClass named versitygw.

Step 4: Create a Bucket

# bucket-claim.yaml
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketClaim
metadata:
  name: my-bucket
  namespace: default
spec:
  bucketClassName: versitygw
  protocols:
    - s3

kubectl apply -f bucket-claim.yaml
kubectl get bucketclaim my-bucket

Step 5: Get Credentials

# bucket-access.yaml
apiVersion: objectstorage.k8s.io/v1alpha1
kind: BucketAccess
metadata:
  name: my-bucket-access
  namespace: default
spec:
  bucketClaimName: my-bucket
  bucketAccessClassName: versitygw
  credentialsSecretName: my-bucket-credentials
  protocol: s3

kubectl apply -f bucket-access.yaml
kubectl get secret my-bucket-credentials -o jsonpath='{.data}' | jq 'map_values(@base64d)'

The Secret contains accessKeyID, accessSecretKey, endpoint, and region. Mount it in your app and you're connected.

Cleanup

kubectl delete -f bucket-access.yaml
kubectl delete -f bucket-claim.yaml

The driver removes the IAM user, bucket policy, and bucket automatically.

Wrapping Up

COSI is still early (v1alpha1), but if you're managing S3 buckets on Kubernetes, it's worth trying. The declarative model fits naturally into GitOps workflows — your bucket definitions live in the same repo as your app manifests, and tools like ArgoCD or Flux handle the rest.

The driver is open source (MIT):

GitHub: isac322/versitygw-cosi-driver
Helm chart: Artifact Hub

If you run into issues or have feature requests, open a GitHub issue. PRs welcome.

Have you tried COSI? I'd be curious to hear about other setups — drop a comment below.

Building an MCP Server for Linux Desktop GUI Automation on Wayland

Byeonghoon Yoo — Mon, 23 Feb 2026 16:14:41 +0000

When I started working on AI agent tooling, I hit a wall: there's no clean way to automate GUI interactions on Wayland. X11 had xdotool and DISPLAY=:99 — Wayland killed all of that, by design. No global input injection, no screen grabbing without portal authorization dialogs.

So I built kwin-mcp, an MCP server that gives AI agents full GUI automation capabilities on Linux desktops, running in a completely isolated KWin Wayland session.

The Problem

Wayland's security model blocks the automation patterns we took for granted on X11. There's no equivalent of pointing tools at a virtual display. XDG RemoteDesktop portals require interactive user authorization — useless for headless automation. And most Wayland compositors don't expose any input injection API at all.

The Solution: Triple Isolation

kwin-mcp creates three layers of isolation for each session:

Private D-Bus bus (dbus-run-session) — no interference with host services
Virtual Wayland compositor (kwin_wayland --virtual) — no windows on your display
Scoped input injection via KWin's EIS D-Bus interface — input stays inside the session

The AI agent never touches your host desktop. You get a fully functional KDE Plasma desktop that exists only in memory.

What It Exposes

The server provides 29 MCP tools:

Category	Tools
Mouse	click, drag, scroll, move, button down/up
Keyboard	type (ASCII), type unicode, key press, key down/up
Touch	tap, swipe, pinch, multi-finger swipe
Screen	screenshot, accessibility tree, find UI elements, wait for element
Session	start, stop, launch app, list/focus windows
System	clipboard get/set, D-Bus calls, Wayland protocol info

Screenshot capture runs at ~30-70ms per frame via KWin's ScreenShot2 D-Bus interface. Any action tool accepts a screenshot_after_ms parameter for burst frame capture without extra round-trips.

Why KWin Specifically?

KWin is (as far as I know) the only Wayland compositor that exposes an EIS (Emulated Input Server) D-Bus interface. This provides the only clean path for input injection without triggering XDG RemoteDesktop authorization dialogs. Since we own the isolated session, we bypass the portal entirely.

Limitations

KDE Plasma 6+ only (no GNOME, no Sway)
US QWERTY keyboard layout for direct typing (Unicode input via wtype works)
AT-SPI2 accessibility coverage varies by application

Getting Started

# Install
pip install kwin-mcp

# Or with uv
uv tool install kwin-mcp

Add to your Claude Code MCP config:

{
  "mcpServers": {
    "kwin-mcp": {
      "command": "kwin-mcp"
    }
  }
}

The project is MIT licensed and available on GitHub and PyPI.

I'd love to hear if anyone has experience with Wayland automation or has ideas for extending this to other compositors. The EIS protocol is theoretically compositor-agnostic, but KWin is the only one implementing it right now.

DEV Community: Byeonghoon Yoo