Imported from jeremylongshore/tons-of-skills-marketplace (plugins/saas-packs/coreweave-pack/skills/coreweave-enterprise-rbac/SKILL.md). Install upstream with npx skills add jeremylongshore/tons-of-skills-marketplace --skill coreweave-enterprise-rbac. Copyright stays with the author (MIT).

CoreWeave Enterprise RBAC

Community-contributed. Not affiliated with, endorsed by, or sponsored by CoreWeave, Inc. CoreWeave is a registered trademark of CoreWeave, Inc.

Overview

CoreWeave runs GPU workloads on Kubernetes, so RBAC maps directly to K8s namespace isolation and ResourceQuotas. Each team gets a dedicated namespace with GPU limits, storage caps, and network policies. This prevents noisy-neighbor problems where one team's training job starves another's inference service. SOC 2 and HIPAA workloads require namespace-level audit logging and team-scoped API key rotation.

Prerequisites

• A verified human or workload identity group from the organization identity provider.
• Cluster-admin approval for namespace, quota, and RoleBinding changes.
• A team owner, approved GPU quota, and data-classification decision for the namespace.

Instructions

1. Create a namespace per team and apply ResourceQuota and NetworkPolicy before granting workload permissions.
2. Bind an IdP group to the smallest suitable ClusterRole; do not bind individual users or reuse a cluster-wide edit role without a documented exception.
3. Run a SubjectAccessReview for the intended verbs and resources, then retain the redacted decision and audit entry with the access request.
4. Review bindings and service-account tokens on a regular schedule; remove access promptly when a team, project, or incident requires it.

Role Hierarchy

Permission Check

import { KubeConfig, RbacAuthorizationV1Api } from '@kubernetes/client-node';

async function checkNamespaceAccess(user: string, namespace: string, verb: string, resource: string): Promise<boolean> {
  const kc = new KubeConfig();
  kc.loadFromDefault();
  const rbac = kc.makeApiClient(RbacAuthorizationV1Api);
  const review = { apiVersion: 'authorization.k8s.io/v1', kind: 'SubjectAccessReview',
    spec: { user, resourceAttributes: { namespace, verb, resource } } };
  const result = await rbac.createSubjectAccessReview(review);
  return result.body.status?.allowed ?? false;
}

Role Assignment

async function assignTeamNamespace(team: string, group: string, gpuLimit: number): Promise<void> {
  await kubectl(`create namespace ${team}`);
  await kubectl(`create resourcequota ${team}-gpu --namespace=${team} --hard=requests.nvidia.com/gpu=${gpuLimit}`);
  await kubectl(`create rolebinding ${team}-access --namespace=${team} --clusterrole=edit --group=${group}`);
  console.log(`Namespace ${team} created with ${gpuLimit} GPU quota bound to ${group}`);
}

async function revokeAccess(team: string, binding: string): Promise<void> {
  await kubectl(`delete rolebinding ${binding} --namespace=${team}`);
}

Audit Logging

interface CoreWeaveAuditEntry {
  timestamp: string; user: string; namespace: string;
  action: 'gpu_request' | 'deploy' | 'scale' | 'delete' | 'quota_change';
  resource: string; gpuCount?: number; result: 'allowed' | 'denied';
}

function logAccess(entry: CoreWeaveAuditEntry): void {
  console.log(JSON.stringify({ ...entry, cluster: process.env.CW_CLUSTER_ID }));
}

RBAC Checklist

• Each team has a dedicated namespace with ResourceQuota
• GPU limits set per namespace to prevent resource starvation
• RoleBindings use AD/OIDC groups, not individual users
• Network policies isolate namespace traffic
• API keys scoped to team namespace, rotated quarterly
• Viewer role assigned to finance/management for cost visibility
• Audit logging enabled for all GPU allocation events

Error Handling

Output

• An isolated team namespace with an enforced GPU quota and network boundary.
• Least-privilege group bindings with a recorded access review and audit trail.
• A repeatable revocation path for a compromised identity or completed project.

Examples

Confirm a deployment identity can create Jobs only in its team namespace before releasing a workload:

kubectl auth can-i create jobs.batch \
  --as=system:serviceaccount:research:trainer \
  --namespace=research
kubectl auth can-i create jobs.batch \
  --as=system:serviceaccount:research:trainer \
  --namespace=production

The expected result is yes only for research. If the second check is allowed, remove the over-broad binding, re-run both checks, and preserve the redacted audit record before resuming deployments.

Resources

• CoreWeave CKS
• Kubernetes RBAC

Next Steps

See coreweave-security-basics.