DevOps Discussion Forum
AKS Namespace Access Control – minesec (RBAC Implementation) - Printable Version

+- DevOps Discussion Forum (https://forums.geekssolutions.io)
+-- Forum: Cloud Computing (https://forums.geekssolutions.io/forumdisplay.php?fid=10)
+--- Forum: DevOps (https://forums.geekssolutions.io/forumdisplay.php?fid=14)
+--- Thread: AKS Namespace Access Control – minesec (RBAC Implementation) (/showthread.php?tid=18)

AKS Namespace Access Control – minesec (RBAC Implementation) - rana - 04-07-2026

AKS Namespace-Restricted Access (minesec) — Production Implementation Guide


Objective
Provide a secure, production-ready method to grant a Linux user access strictly limited to the minesec namespace in an AKS cluster using Kubernetes RBAC and kubeconfig.

This approach ensures:
  • Zero cluster-wide exposure
  • Controlled namespace isolation
  • Auditable access model


Architecture Overview

Code:
Linux User (minesecuser)
│
▼
kubeconfig (Token-based auth)
│
▼
ServiceAccount (minesec namespace)
│
▼
Role (Namespace scoped permissions)
│
▼
RoleBinding (Access enforcement)

Key Principle:
Access is not tied to Linux user directly — it is mapped via ServiceAccount + Token.


Step 1: Create Linux User

Code:
sudo useradd -m minesecuser
sudo chsh -s /bin/bash minesecuser

Why this matters:
Separates OS-level identity from cluster-level permissions.


Step 2: Create ServiceAccount

Code:
apiVersion: v1
kind: ServiceAccount
metadata:
  name: minesecuser
  namespace: minesec

Code:
kubectl apply -f serviceaccount.yaml

Important:
Never reuse ServiceAccounts across users. One identity = one ServiceAccount.


Step 3: Create Role (Namespace Scoped)

Code:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: minesecuser-role
  namespace: minesec
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

Code:
kubectl apply -f role.yaml

Production Warning:
This gives full access inside the namespace.

In real environments, restrict it like:

Code:
resources: ["pods","deployments","services"]
verbs: ["get","list","watch"]


Step 4: Create RoleBinding

Code:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: minesecuser-binding
  namespace: minesec
subjects:
- kind: ServiceAccount
  name: minesecuser
  namespace: minesec
roleRef:
  kind: Role
  name: minesecuser-role
  apiGroup: rbac.authorization.k8s.io

Code:
kubectl apply -f rolebinding.yaml

What this does:
This is the enforcement layer — without RoleBinding, access = zero.


Step 5: Generate Token

Code:
kubectl -n minesec create token minesecuser --duration=8760h > /root/minesecuser.token
chmod 600 /root/minesecuser.token

Critical Insight:
This token is effectively a password to your cluster. Treat it as a secret.


Step 6: Extract Cluster Details

Code:
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'

Code:
kubectl config view --minify --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}'


Step 7: Create kubeconfig file

Configure Linux User
Code:
mkdir -p /home/minesecuser/.kube
cp config /home/minesecuser/.kube/config
chown -R minesecuser:minesecuser /home/minesecuser/.kube
chmod 600 /home/minesecuser/.kube/config

Contents
Code:
apiVersion: v1
kind: Config

clusters:
- name: aks-cluster
  cluster:
    server: https://<AKS-API-SERVER>
    certificate-authority-data: <BASE-64-CA>

users:
- name: minesecuser
  user:
    token: <TOKEN>

contexts:
- name: minesec-context
  context:
    cluster: aks-cluster
    user: minesecuser
    namespace: minesec

current-context: minesec-context

Key Design Point:
Namespace is hardcoded → prevents accidental cross-namespace access.


Step 8: Validation

Code:
su - minesecuser
kubectl get pods

Negative Testing (Important):

Code:
kubectl get pods -n default
kubectl get ns
kubectl get nodes

Expected:
All above should return Forbidden


Security Best Practices
  • Never share kubeconfig over email or chat
  • Rotate tokens periodically (recommended: 30–90 days)[]Avoid wildcard "" permissions in production
  • Use Azure AD + RBAC for enterprise identity integration
  • Audit access via Kubernetes audit logs / Azure Monitor
  • Store tokens securely (Azure Key Vault preferred)



Production Risks (Do Not Ignore)
  • Leaked token = full namespace compromise
  • Wildcard RBAC = privilege escalation risk
  • Long-duration tokens = security exposure
  • Manual kubeconfig distribution = audit gap


Recommended Enterprise Upgrade Path
  • Replace token-based auth with Azure AD RBAC
  • Use AAD Groups instead of ServiceAccounts
  • Use short-lived tokens (OIDC)
  • Implement Just-in-Time (JIT) access


Summary
  • Achieved strict namespace isolation using RBAC
  • Mapped Linux user → ServiceAccount via kubeconfig
  • Prevented cluster-wide access
  • Established secure and auditable access pattern