Skip to main content

Identity & Access Management (Keystone)

Okustera IAM is powered by OpenStack Keystone, providing enterprise-grade multi-tenancy, Role-Based Access Control (RBAC), and Kubernetes Workload Identity.


Architectural Principles​

  • Multi-Project Isolation: Every customer environment is housed in an isolated Keystone project. Resources in one tenant cannot view or query resources in another.
  • Granular RBAC: Control read, write, and administrative permissions using predefined roles (admin, member, reader) or custom policy rules.
  • Workload Identity (Pod IAM - Optional): By default, platform workloads route directly with standard scoped credentials (zero latency overhead). For enterprise environments requiring strict zero-trust security, Pod IAM can be activated so Kubernetes pods exchange short-lived ServiceAccount projected tokens for Okustera scoped IAM credentials dynamically.

Operating Modes​

Okustera supports two distinct operational modes for workload access:

Operational ModeIngress BehaviorAuthorizer FootprintWorkload Credential TypeUse Case
Standard Mode (Default)Direct routing to omc-backend (0ms subrequest latency)0 replicas (omc-iam-authorizer scaled down)OpenStack Keystone Application Credentials / Ceph S3 Access KeysLean development, high-throughput microservices, minimal cluster overhead
Enforced Mode (Optional)APISIX forward-auth plugin intercepts all /api/* traffic2 replicas running in omc-iam-systemProjected K8s ServiceAccount JWTs validated against cluster JWKSZero-trust compliance, strict least-privilege pod isolation, audit-ready STS

Managing Workload Authentication via Terraform​

Users can configure workload authentication declaratively in Terraform according to the active mode:

1. Standard Mode (Default / Direct Routing)​

In Standard Mode, workloads authenticate using unprivileged, scoped Keystone Application Credentials and standard S3 access keys provisioned via Terraform:

# 1. Provision a scoped Keystone Application Credential
resource "openstack_identity_application_credential_v3" "workload_cred" {
name = "data-pipeline-worker-cred"
description = "Scoped credential for microservice pods"
roles = ["member"]
}

# 2. Mount the credentials into the workload namespace as a Secret
resource "kubernetes_secret" "workload_auth" {
metadata {
name = "workload-keystone-auth"
namespace = "production"
}
data = {
OS_AUTH_TYPE = "v3applicationcredential"
OS_AUTH_URL = "https://keystone.okustera.com/v3"
OS_APPLICATION_CREDENTIAL_ID = openstack_identity_application_credential_v3.workload_cred.id
OS_APPLICATION_CREDENTIAL_SECRET = openstack_identity_application_credential_v3.workload_cred.secret
}
}

# 3. Object Storage (S3 / Ceph RGW)
resource "okustera_s3_bucket" "data_lake" {
name = "tenant-data-lake"
quota_gb = 100
}

2. Enforced Mode (Declarative Pod IAM via Kubernetes Manifests)​

When Enforced Mode is active, workloads declare fine-grained route policies and bindings directly using Terraform's kubernetes_manifest:

# 1. Declare the OMCIAMRole CRD
resource "kubernetes_manifest" "storage_operator_role" {
manifest = {
apiVersion = "iam.opencloud.local/v1alpha1"
kind = "OMCIAMRole"
metadata = {
name = "storage-operator-role"
namespace = "production"
}
spec = {
description = "Grants access to storage endpoints and presigned uploads"
endpointPolicies = [
{
path = "/api/v1/storage/*"
methods = ["GET", "POST"]
effect = "Allow"
},
{
path = "/api/v1/billing/*"
methods = ["*"]
effect = "Deny"
}
]
openstackRoles = ["member"]
}
}
}

# 2. Bind the Kubernetes ServiceAccount to the OMCIAMRole
resource "kubernetes_manifest" "storage_operator_binding" {
manifest = {
apiVersion = "iam.opencloud.local/v1alpha1"
kind = "OMCPodIdentityBinding"
metadata = {
name = "storage-operator-binding"
namespace = "production"
}
spec = {
serviceAccountName = "storage-operator-sa"
roleRef = {
name = "storage-operator-role"
}
}
}
}

Managing Users & Roles in the Cloud Portal​

The Okustera Cloud Portal (/iam) provides self-service identity management for tenant administrators:

1. Team Role Hierarchy​

Each tenant project supports granular Role-Based Access Control (RBAC):

RolePermissions & ScopeTypical Assignment
adminFull read, write, update, delete, and billing management across all project resources.Team Leads, DevOps Architects
memberFull operational control to launch VMs, deploy functions, provision databases, and create S3 buckets. Cannot modify project billing or invite users.Software Engineers, Data Scientists
readerRead-only inspection of dashboards, running instances, and logs. Cannot create or mutate resources.Security Auditors, Contractors, SREs on review

2. Interactive IAM Policy Simulator​

Before deploying automated CI/CD pipelines or microservices, test their permission boundaries using the IAM Policy Simulator:

  1. In the Cloud Portal, navigate to IAM $\to$ Policy Simulator (/iam).
  2. Select target identity: Role (e.g. member) or Service Account token.
  3. Select API Endpoint path (e.g. /api/v1/storage/volumes) and HTTP Method (POST).
  4. Click Simulate Access.
  5. The policy engine evaluates the request against current Keystone and Pod IAM policies, returning:
    • Verdict: ALLOWED or DENIED.
    • Matching Rule: Details which policy granted or blocked access.

REST API Reference​

  • GET /api/v1/identity/users — List users in current project.
  • POST /api/v1/identity/users — Create user account with initial credentials.
  • GET /api/v1/identity/roles — List available IAM roles (admin, member, reader).
  • POST /api/v1/identity/role-assignments — Assign a role to a user within a project.
  • DELETE /api/v1/identity/role-assignments — Revoke a user's role assignment.
  • POST /api/v1/iam/simulate — Evaluate whether an identity has permission to invoke an endpoint.
  • POST /api/v1/iam/sts/assume-role — Exchange workload identity token for short-lived credentials.