AKS Namespace Access Control – minesec (RBAC Implementation)

[rana]

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