OpsBoard: Using k8or Common CRDs for AWS Cloud Service Integration

By Anna V. April 23, 2025. Revised. Version: 0.0.09

📌 Overview

k8or OpsBoard now supports Common Resources, a reusable collection of cloud-native integrations based on Kubernetes Custom Resource Definitions (CRDs). These include AWS:

  • S3 Buckets

  • DynamoDB Tables

  • MySQL Databases (via RDS)

  • Other AWS Services via the ACK controllers

Developers can discover, transfer, configure, and connect to these resources inside their application environments (Dev, Test, Stage, Prod) without redefining AWS infrastructure each time.

🔁 How It Works: Step-by-Step

Step 1: Navigate to Common Category

  1. On the OpsBoard dashboard, look for the new category:

    CATEGORY > Common

  2. You'll see a list of AWS CRDs such as:

    • s3-bucket-standard

    • dynamodb-default

    • mysql-rds-basic

Each CRD is a predefined configuration and includes its own HELM chart or manifest.

Step 2: Transfer to the Environment

  1. Click Transfer on a Common CRD.

  2. Choose the environment (e.g., Development) to send this resource to.

  3. The CRD is now copied into that environment namespace, retaining its config.

✅ Note: You can mutate the transferred CRD after copying. Each environment holds its own copy.

Step 3: Configure Cloud Resource (Access)

  1. Click Access on the CRD.

  2. You’ll be presented with an editable configuration UI for:

    • Bucket Name, e.g., aircraft-logs-543

    • AWS Access Key / Secret (or use IRSA if configured)

    • Region, IAM Role, Storage Class, etc.

  3. After saving, the config is written to:

    • A namespace ConfigMap

    • The external ViewPort registry

This ensures persistence and cluster visibility.

Step 4: Expose to Other Services

  1. Click Expose on the CRD.

  2. This makes the resource discoverable by other microservices in the same environment (via labels, selectors, or config references).

  3. A FE/MW MSV can now click Expose on the CRD, read the reference, and paste/attach it via their Access button.

🧠 Think of Expose as a "shared service declaration" and Access as a "service consumer configuration".

🔗 Dependency Tracking

All dependencies are tracked automatically:

  • Which MSVs (e.g., MW components) access which CRD

  • Which environments contain what configuration

  • Visual overlays in the UI (optional enhancement) showing connections

💡 Use Case Example

  • Upload middleware MSV: order-processor

  • Transfer s3-logs-bucket from Common to Dev

  • Click on Access and configure it with test credentials

  • Expose the CRD

  • MW MSV reads the config and links it via Access

Result: the MW can now write logs or fetch data from a centralized S3 bucket.

📌 Notes

  • This workflow supports both manual UI-based actions and automated GitOps-based deployments using manifest injection.

  • Changes made via the Access form are version-tracked and audit-logged.

  • CRDs can be used by multiple MSVs but are environment-scoped.

PreviousTransfer ImageNextAWS Controllers for k8or

Last updated