Auth Bypass on Kubernetes

Auth bypass in Kubernetes environments typically exploits the complex interplay between service accounts, RBAC permissions, and API server authentication mechanisms. The most common Kubernetes-specific auth bypass occurs when service accounts are mounted with overly permissive permissions or when token-based authentication isn't properly scoped.

A classic vulnerability pattern involves default service account tokens being mounted into pods without restriction. Consider this vulnerable deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: vulnerable-app
spec:
  template:
    spec:
      serviceAccountName: default
      containers:
      - name: app
        image: myapp:latest
        volumeMounts:
        - name: service-account
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      volumes:
      - name: service-account
        secret:
          secretName: default-token-abc123

This configuration allows any container to access the service account token and potentially escalate privileges by making authenticated API calls to the Kubernetes API server. An attacker who gains code execution in this pod could use the token to list all pods, read secrets, or modify deployments.

Another Kubernetes-specific auth bypass pattern involves misconfigured admission controllers. When validating admission controllers are disabled or improperly configured, requests that should be rejected can bypass authentication entirely:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: security-webhook
spec:
  webhooks:
  - name: security.example.com
    rules:
    - operations: ["CREATE", "UPDATE"]
      apiGroups: ["*"]
      apiVersions: ["*"]
      resources: ["*"]
    failurePolicy: Ignore  # Critical: should be Fail

With failurePolicy: Ignore, if the webhook service is unreachable, requests bypass validation entirely rather than being rejected.

Service mesh configurations can also introduce auth bypass vulnerabilities. When mTLS is misconfigured or when JWT validation is bypassed in ingress controllers, requests can traverse the cluster without proper authentication:

apiVersion: networking.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: permissive-policy
spec:
  selector:
    matchLabels:
      app: myapp
  rules:
  - from:
    - source:
        principals: ["*"]  # Bypasses authentication entirely

This policy allows any authenticated or unauthenticated request to reach the service, effectively bypassing authorization checks.

Detecting auth bypass vulnerabilities in Kubernetes requires examining both configuration files and runtime behavior. middleBrick's Kubernetes-specific scanning identifies these issues by analyzing API endpoints, service account configurations, and RBAC bindings.

For service account vulnerabilities, middleBrick scans for exposed tokens and overly permissive service account mounts:

$ middlebrick scan https://kubernetes.default.svc

=== Kubernetes Auth Bypass Scan ===
• Service Account Exposure: HIGH RISK
  - Found mounted service account token in /var/run/secrets/kubernetes.io/serviceaccount
  - Token has cluster-admin RBAC binding
  - Recommendation: Use least-privilege service accounts

The scanner examines API server endpoints for authentication bypass opportunities, testing whether unauthenticated requests can access protected resources. It specifically looks for:

• Missing authentication middleware in API routes
• Service account tokens with excessive permissions
• Misconfigured admission controller failure policies
• Open authorization policies in service meshes
• Exposed Kubernetes API endpoints

middleBrick's OpenAPI analysis resolves all $ref references in Kubernetes manifests and validates that authentication requirements are properly enforced across the entire API surface. The scanner generates a security risk score (0-100) with letter grades and provides specific remediation guidance for each finding.

For CI/CD integration, the middleBrick GitHub Action can fail builds when auth bypass vulnerabilities are detected:

name: Security Scan
on: [pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v4
    - name: Run middleBrick Scan
      uses: middleBrick/middleBrick-action@v1
      with:
        target: https://kubernetes.default.svc
        fail-on-severity: high
        token: ${{ secrets.MIDDLEBRICK_TOKEN }}

This configuration automatically blocks deployments containing auth bypass vulnerabilities before they reach production.

Remediating auth bypass vulnerabilities in Kubernetes requires a defense-in-depth approach using native Kubernetes security features. The foundation is implementing least-privilege service accounts and properly scoped RBAC permissions.

First, create minimal service accounts with explicit permissions:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-service-account

---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: app-role
spec:
  rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: app-rolebinding
subjects:
- kind: ServiceAccount
  name: app-service-account
  namespace: default
roleRef:
  kind: Role
  name: app-role
  apiGroup: rbac.authorization.k8s.io

This configuration ensures the service account can only access specific resources with specific verbs, preventing privilege escalation through the API server.

For admission controller security, configure validating webhooks with strict failure policies:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: security-webhook
spec:
  webhooks:
  - name: security.example.com
    rules:
    - operations: ["CREATE", "UPDATE"]
      apiGroups: ["*"]
      apiVersions: ["*"]
      resources: ["*"]
    failurePolicy: Fail  # Critical: Reject on failure
    clientConfig:
      service:
        name: webhook-service
        namespace: default
        path: /validate

The failurePolicy: Fail setting ensures requests are rejected rather than bypassed when the webhook is unavailable.

Service mesh authorization policies should be explicitly defined rather than permissive:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: strict-policy
spec:
  selector:
    matchLabels:
      app: myapp
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/default/sa/specific-service-account"]
    to:
    - operation:
        methods: ["GET", "POST"]
        paths: ["/api/*"]

This policy restricts access to specific service accounts and HTTP methods, preventing unauthorized access.

For API server authentication, enable and properly configure authentication plugins:

apiVersion: v1
kind: APIServer
metadata:
  name: kube-apiserver
spec:
  authentication:
    webhook:
      cacheTTL: 2m
      tokenReview:
        version: v1
    timeoutSeconds: 30
  authorization:
    webhook:
      cacheAuthorizedTTL: 5m
      cacheUnauthorizedTTL: 30s

These configurations ensure authentication and authorization decisions are properly enforced with appropriate caching for performance.