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 Mode | Ingress Behavior | Authorizer Footprint | Workload Credential Type | Use 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 Keys | Lean development, high-throughput microservices, minimal cluster overhead |
| Enforced Mode (Optional) | APISIX forward-auth plugin intercepts all /api/* traffic | 2 replicas running in omc-iam-system | Projected K8s ServiceAccount JWTs validated against cluster JWKS | Zero-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):
| Role | Permissions & Scope | Typical Assignment |
|---|---|---|
admin | Full read, write, update, delete, and billing management across all project resources. | Team Leads, DevOps Architects |
member | Full operational control to launch VMs, deploy functions, provision databases, and create S3 buckets. Cannot modify project billing or invite users. | Software Engineers, Data Scientists |
reader | Read-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:
- In the Cloud Portal, navigate to IAM $\to$ Policy Simulator (
/iam). - Select target identity: Role (e.g.
member) or Service Account token. - Select API Endpoint path (e.g.
/api/v1/storage/volumes) and HTTP Method (POST). - Click Simulate Access.
- The policy engine evaluates the request against current Keystone and Pod IAM policies, returning:
- Verdict:
ALLOWEDorDENIED. - Matching Rule: Details which policy granted or blocked access.
- Verdict:
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.