KubeSphere and Kubernetes Security: Complete Hardening Guide for 2026

Table of Contents

1. What is KubeSphere
2. Kubernetes Is Not Secure by Default
3. The 4C Security Model: Cloud, Cluster, Container, Code
4. Install KubeSphere on an Existing Kubernetes Cluster
5. Security Layer 1: RBAC — Control Who Can Do What
6. Security Layer 2: Pod Security Standards
7. Security Layer 3: Network Policies — Default Deny Everything
8. Security Layer 4: Secrets Management
9. Security Layer 5: Image Security and Supply Chain
10. Security Layer 6: API Server Hardening
11. Security Layer 7: etcd Encryption at Rest
12. Security Layer 8: Audit Logging
13. Security Layer 9: Runtime Threat Detection with Falco
14. KubeSphere Security Features: Multi-Tenancy and RBAC UI
15. Kubernetes Security Checklist 2026
16. KubeSphere vs Rancher vs OpenShift: Security Comparison
17. Common Misconfigurations and How to Fix Them
18. Next Steps

Kubernetes is not secure by default — a default installation allows pods to run as root, has no network segmentation between pods, stores secrets base64-encoded (not encrypted), and grants broad default service account permissions. Getting from “we have Kubernetes” to “we have secure Kubernetes” requires explicit configuration at every layer. This guide covers that full journey, using KubeSphere as the management layer that makes many of these security controls accessible through a web UI instead of raw YAML files.

What is KubeSphere

KubeSphere is a multi-tenant enterprise-grade open-source Kubernetes container platform with full-stack automated IT operations and streamlined DevOps workflows. It provides a developer-friendly wizard web UI, helping enterprises build a more robust and feature-rich Kubernetes platform, which includes the most common functionalities needed for enterprise Kubernetes strategies. A CNCF-certified Kubernetes platform, 100% open-source, built and improved by the community.

KubeSphere is not a replacement for Kubernetes — it’s a management layer that runs on top of an existing Kubernetes cluster and adds:

• Web UI for cluster and workload management
• Multi-tenancy with workspace isolation and fine-grained RBAC
• DevOps pipelines (Jenkins-based CI/CD built-in)
• Observability — built-in monitoring, logging, and alerting
• Service mesh (Istio integration)
• Application marketplace for one-click deployments
• Security management — audit logs, network policies, pod security via UI

KubeSphere can run anywhere from on-premise datacenter to any cloud to edge. In addition, it can be deployed on any version-compatible Kubernetes cluster. KubeSphere consumes very few resources, and you can optionally install additional extensions after installation.

KubeSphere vs plain Kubernetes:

	Plain Kubernetes	KubeSphere
Management interface	kubectl CLI	Web UI + kubectl
Multi-tenancy	Manual RBAC YAML	Built-in workspace isolation
Monitoring	External (Prometheus)	Built-in (WhizardTelemetry)
Logging	External (Loki/ELK)	Built-in (Fluent Operator)
Security policies	Manual YAML	UI + policy enforcement
CI/CD	External (GitLab, Jenkins)	Built-in pipelines
Learning curve	High	Moderate

Kubernetes Is Not Secure by Default

Before touching any configuration, understand what a default Kubernetes cluster leaves open:

Default Kubernetes cluster — what's exposed out of the box:

✗ Pods can run as root (UID 0)
✗ Pods can access the host network and filesystem
✗ All pods can talk to all other pods (no network segmentation)
✗ Secrets stored as base64 — not encrypted at rest
✗ Default service accounts have broad API permissions
✗ No audit logging enabled
✗ API server may be exposed without strong authentication
✗ etcd not encrypted by default

The CIS Kubernetes Benchmark contains 200+ recommendations; the highest-impact priorities are RBAC enforcement, Pod Security Standards, network policies, etcd encryption, and audit logging.

This guide addresses each of these systematically.

The 4C Security Model: Cloud, Cluster, Container, Code

Modern Kubernetes security revolves around a defense-in-depth model, often described as the 4C’s: Cloud, Cluster, Container, and Code. Each layer fails differently and demands different controls.

┌─────────────────────────────────────────┐
│  CLOUD                                  │
│  IAM, VPC, metadata service protection │
│  ┌─────────────────────────────────┐    │
│  │  CLUSTER                        │    │
│  │  RBAC, API server, etcd, audit │    │
│  │  ┌──────────────────────────┐   │    │
│  │  │  CONTAINER               │   │    │
│  │  │  Images, securityContext │   │    │
│  │  │  ┌───────────────────┐   │   │    │
│  │  │  │  CODE             │   │   │    │
│  │  │  │  SAST, SCA, SBOM  │   │   │    │
│  │  │  └───────────────────┘   │   │    │
│  │  └──────────────────────────┘   │    │
│  └─────────────────────────────────┘    │
└─────────────────────────────────────────┘

A cloud-layer compromise (stolen IAM credentials, exposed metadata service) bypasses every container-layer hardening underneath. Start securing from the outside in.

Install KubeSphere on an Existing Kubernetes Cluster

KubeSphere deploys on any compatible Kubernetes cluster (v1.21+) via Helm:

Prerequisites:

• A running Kubernetes cluster (k3s, kubeadm, or managed EKS/GKE/AKS)
• kubectl configured and connected to the cluster
• helm v3+ installed
• At least 2 CPU cores and 4GB RAM available

Install KubeSphere core:

helm upgrade --install \
  -n kubesphere-system \
  --create-namespace \
  ks-core \
  https://charts.kubesphere.io/main/ks-core-1.1.3.tgz \
  --debug --wait

Monitor the installation:

kubectl get pods -n kubesphere-system -w

Wait for all pods to show Running:

kubectl get pods -n kubesphere-system
# NAME                                    READY   STATUS    RESTARTS   AGE
# ks-controller-manager-xxx               1/1     Running   0          2m
# ks-apiserver-xxx                        1/1     Running   0          2m
# ks-console-xxx                          1/1     Running   0          2m

Get the console URL:

kubectl get svc ks-console -n kubesphere-system
# NAME         TYPE       CLUSTER-IP    EXTERNAL-IP   PORT(S)        AGE
# ks-console   NodePort   10.96.x.x     <none>        80:30880/TCP   2m

Access at http://<node-ip>:30880 — default credentials: admin / P@88w0rd

Change the default password immediately — Admin → User Settings → Password Settings.

For all-in-one installation (Kubernetes + KubeSphere together):

# Using KubeKey for all-in-one single-node install
curl -sfL https://get-kk.kubesphere.io | sh -
./kk create cluster --with-kubesphere

Security Layer 1: RBAC — Control Who Can Do What

Role-Based Access Control (RBAC) is a highly granular access control method that restricts users from certain assets based on their position within the organization. It grants users access only to the most essential resources they need to perform their tasks.

Kubernetes RBAC concepts:

Subject (who)     →  RoleBinding  →  Role (what permissions)
User/Group/SA          binds           in a namespace

ClusterRoleBinding connects Subjects to ClusterRoles (cluster-wide)

Create a read-only role for developers:

# developer-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: developer-readonly
rules:
  # Can view pods, deployments, services
  - apiGroups: ["", "apps"]
    resources: ["pods", "deployments", "services", "configmaps"]
    verbs: ["get", "list", "watch"]
  # Can exec into pods (for debugging)
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]
  # Can view pod logs
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]
  # Cannot: create/delete resources, access secrets, modify RBAC
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-readonly-binding
  namespace: production
subjects:
  - kind: User
    name: jane.doe@company.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-readonly
  apiGroup: rbac.authorization.k8s.io

Restrict default service account permissions:

# Deny default service account access to the API
# Apply to every namespace that doesn't need API access
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: deny-default-sa
  namespace: production
subjects:
  - kind: ServiceAccount
    name: default
    namespace: production
roleRef:
  kind: ClusterRole
  name: view  # Grant read-only at most — or create a custom empty role
  apiGroup: rbac.authorization.k8s.io

In KubeSphere: RBAC is managed through the web UI under Access Control → Roles. KubeSphere adds an extra workspace layer on top of Kubernetes RBAC — workspaces provide isolated environments for teams with their own quota, RBAC, and DevOps pipelines.

Audit your current RBAC:

# Check who has cluster-admin
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name == "cluster-admin") | .subjects'

# List all service accounts with roles
kubectl get rolebindings,clusterrolebindings -A -o wide

# Use kubectl-who-can to check permissions
kubectl who-can create pods -n production

Security Layer 2: Pod Security Standards

Pod Security Standards (replacing deprecated PodSecurityPolicy in Kubernetes 1.25+) define three profiles: Privileged (unrestricted), Baseline (blocks known privilege escalation), and Restricted (full hardening for application workloads).

Enable Pod Security Standards at namespace level:

# Label namespaces to enforce security profiles
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    # Enforce restricted profile — reject non-compliant pods
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    # Warn on baseline violations
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/warn-version: latest
    # Audit all violations
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: latest

Apply to existing namespace:

kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/warn=restricted

Write secure pod specs that comply with the Restricted profile:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: secure-app
  namespace: production
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true           # Never run as root
        runAsUser: 1000              # Specific non-root UID
        runAsGroup: 1000
        fsGroup: 2000
        seccompProfile:
          type: RuntimeDefault       # Apply default seccomp profile

      containers:
        - name: app
          image: myapp:1.2.3        # Always pin to specific version, not :latest
          securityContext:
            allowPrivilegeEscalation: false   # Critical — prevents sudo/setuid
            readOnlyRootFilesystem: true      # App can't write to its own FS
            capabilities:
              drop: ["ALL"]          # Drop all Linux capabilities
              add: []                # Add back only what's strictly needed

          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "512Mi"        # Always set limits — prevents noisy neighbor

          # Health checks — required for production
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080

      # Don't mount service account tokens unless needed
      automountServiceAccountToken: false

Security Layer 3: Network Policies — Default Deny Everything

A restrictive approach works best: network policies should deny traffic by default, only allowing explicitly permitted connections.

By default, all Kubernetes pods can communicate with all other pods. Implementing a default-deny policy and then explicitly allowing needed connections is the correct security posture.

Step 1: Default deny all ingress and egress:

# Apply to every namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}    # Applies to all pods in the namespace
  policyTypes:
    - Ingress
    - Egress

Step 2: Allow only what’s needed:

# Allow API pods to receive traffic from ingress only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: ingress-nginx
      ports:
        - protocol: TCP
          port: 8080
---
# Allow API pods to talk to the database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgresql
      ports:
        - protocol: TCP
          port: 5432
---
# Allow DNS resolution for all pods (required for service names to work)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Note: Network policies require a CNI plugin that supports them (Calico, Cilium, Weave). The default kubenet CNI does not enforce network policies — installing policies without a supporting CNI has no effect.

Security Layer 4: Secrets Management

Kubernetes Secrets are base64-encoded, not encrypted. For production you need external secrets management.

Problem: A base64-encoded secret is trivially decoded:

echo "bXlwYXNzd29yZA==" | base64 -d
# mypassword

Anyone with read access to the Secret resource can decode it instantly.

Solution 1: Encrypt secrets at rest in etcd

Add an encryption configuration to the API server:

# /etc/kubernetes/encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>  # openssl rand -base64 32
      - identity: {}    # Fallback for decrypting existing unencrypted secrets

Add to the API server flags:

--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

Solution 2: External Secrets Operator (recommended for production)

# ExternalSecret pulls from HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
  namespace: production
spec:
  refreshInterval: 5m
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-credentials
    creationPolicy: Owner
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

Solution 3: Seal secrets for GitOps (Sealed Secrets)

# Install Sealed Secrets controller
helm install sealed-secrets \
  https://bitnami-labs.github.io/sealed-secrets/sealed-secrets-1.0.0.tgz \
  --namespace kube-system

# Seal a secret (safe to commit to Git)
kubeseal --format yaml < secret.yaml > sealed-secret.yaml
git add sealed-secret.yaml  # Now safe to commit

Security Layer 5: Image Security and Supply Chain

Supply-chain hygiene is enforced at admission, not in build pipelines alone: sign images with Cosign/Sigstore, generate SBOMs with Syft or Trivy, allowlist registries via Kyverno or OPA Gatekeeper, and prefer distroless or Chainguard base images.

Scan images with Trivy before deployment:

# Scan for vulnerabilities
trivy image myapp:1.2.3

# Scan in CI pipeline — fail on HIGH or CRITICAL
trivy image --exit-code 1 --severity HIGH,CRITICAL myapp:1.2.3

# Generate SBOM (Software Bill of Materials)
trivy image --format cyclonedx --output sbom.json myapp:1.2.3

Enforce image policies with Kyverno:

# Only allow images from your private registry
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Images must come from registry.yourdomain.com"
        pattern:
          spec:
            containers:
              - image: "registry.yourdomain.com/*"
---
# Disallow :latest tag in production
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
    - name: require-image-tag
      match:
        any:
          - resources:
              kinds: [Pod]
              namespaces: [production]
      validate:
        message: "Image tag :latest is not allowed in production"
        pattern:
          spec:
            containers:
              - image: "!*:latest"

Sign images with Cosign:

# Sign an image after building
cosign sign --key cosign.key registry.yourdomain.com/myapp:1.2.3

# Verify a signature before deploying
cosign verify --key cosign.pub registry.yourdomain.com/myapp:1.2.3

Security Layer 6: API Server Hardening

The API server is the entry point for everything in Kubernetes. Harden it:

# kube-apiserver flags (add to /etc/kubernetes/manifests/kube-apiserver.yaml)

# Enable audit logging
--audit-log-path=/var/log/kubernetes/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100
--audit-policy-file=/etc/kubernetes/audit-policy.yaml

# Disable anonymous authentication
--anonymous-auth=false

# Enable RBAC authorization
--authorization-mode=Node,RBAC

# Restrict admission controllers
--enable-admission-plugins=NodeRestriction,PodSecurity,ResourceQuota,LimitRanger

# Disable insecure port (should already be 0 in modern K8s)
--insecure-port=0

# Enable TLS
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key

Security Layer 7: etcd Encryption at Rest

etcd stores all cluster state — including secrets, configmaps, and RBAC policies. Without encryption, anyone with etcd access has everything.

Verify etcd is using TLS:

# Check etcd is not exposed without auth
kubectl get pods -n kube-system -l component=etcd -o yaml | grep "listen-client-urls"
# Should show https://, not http://

Verify secret encryption is working:

# Write a test secret
kubectl create secret generic test-secret \
  --from-literal=password=testvalue

# Read directly from etcd (should show encrypted gibberish, not "testvalue")
ETCDCTL_API=3 etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get /registry/secrets/default/test-secret | hexdump -C | head

# Should start with "k8s:enc:aescbc:v1:key1:" if encryption is working

Security Layer 8: Audit Logging

Audit logging records every API call made to the cluster — who did what, when. Essential for forensics and compliance.

# /etc/kubernetes/audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Log all requests to secrets at RequestResponse level
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]

  # Log authentication failures at Request level
  - level: Request
    users: ["system:anonymous"]
    verbs: ["get", "list", "watch"]

  # Log pod exec/attach (high-risk operations)
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach"]

  # Log all changes (write operations) at Metadata level
  - level: Metadata
    verbs: ["create", "update", "patch", "delete"]

  # Don't log routine read operations (too noisy)
  - level: None
    verbs: ["get", "list", "watch"]
    resources:
      - group: ""
        resources: ["endpoints", "services", "namespaces"]

Ship audit logs to your Grafana Loki stack for centralized storage and alerting:

# Alert on any cluster-admin binding being created
{job="kubernetes-audit"} |= "cluster-admin" |= "create"

# Alert on secret access by unknown users
{job="kubernetes-audit"} | json | objectRef_resource="secrets" | user_username!~"system:.*"

Security Layer 9: Runtime Threat Detection with Falco

Falco watches system calls inside running containers in real time and alerts when behavior deviates from expected patterns:

# falco-values.yaml for Helm installation
falco:
  rules_file:
    - /etc/falco/falco_rules.yaml
    - /etc/falco/k8s_audit_rules.yaml

  json_output: true
  json_include_output_property: true

  # Alert on these events:
  # - Shell spawned in a container
  # - Write to /etc or /bin directories
  # - Unexpected network connection
  # - Privilege escalation attempt
  # - Container escape attempts

Install Falco:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm install falco falcosecurity/falco \
  --namespace falco \
  --create-namespace \
  -f falco-values.yaml

Example Falco rule — alert on shell in container:

- rule: Shell Spawned in Container
  desc: A shell was spawned in a container (unexpected at runtime)
  condition: >
    spawned_process
    and container
    and shell_procs
    and not proc.pname in (shell_binaries)
  output: >
    Shell spawned in container
    (user=%user.name container=%container.name image=%container.image.repository:%container.image.tag
     shell=%proc.name parent=%proc.pname)
  priority: WARNING
  tags: [container, shell, mitre_execution]

KubeSphere Security Features: Multi-Tenancy and RBAC UI

KubeSphere adds a security management layer that makes many of the above controls accessible through a UI:

Workspace isolation:

KubeSphere workspace model:

Platform Admin
  └── Workspace A (Team Frontend)
        ├── Project (namespace): frontend-prod
        ├── Project (namespace): frontend-staging
        └── Members: alice (admin), bob (operator), carol (viewer)
  └── Workspace B (Team Backend)
        ├── Project (namespace): backend-prod
        └── Members: dave (admin), eve (operator)

Members of Workspace A cannot see or access resources in Workspace B — enforced through Kubernetes RBAC automatically by KubeSphere.

Built-in security features in KubeSphere:

• Access Control → Roles — create and assign roles without writing YAML
• Access Control → Login History — audit who logged in, when, from where
• Cluster → Monitoring — built-in dashboards via WhizardTelemetry
• Toolbox → Audit Logs — search and filter Kubernetes audit events in the UI
• Projects → Network Policies — create network policies through a form
• KubeSphere Enterprise 4.2 additionally provides image security hardening, two-factor authentication, and vulnerability fixes compared to the open-source version.

Kubernetes Security Checklist 2026

The OWASP Kubernetes Top 10 (2025) — K01 (insecure workload configs), K02 (overly permissive authorization), and K05 (missing network segmentation) — account for the majority of findings on production clusters.

Use this checklist to track your cluster’s security posture:

Access Control:

• [ ] RBAC enabled and all default service account permissions reviewed
• [ ] No subjects bound to cluster-admin except break-glass accounts
• [ ] All user access uses short-lived certificates or OIDC tokens (not static passwords)
• [ ] API server anonymous authentication disabled (--anonymous-auth=false)
• [ ] kubectl access requires MFA (via OIDC provider)

Workload Security:

• [ ] Pod Security Standards enforced on all production namespaces (Restricted profile)
• [ ] All containers run as non-root (runAsNonRoot: true)
• [ ] allowPrivilegeEscalation: false set on all containers
• [ ] All Linux capabilities dropped (capabilities.drop: ALL)
• [ ] Resource limits set on all containers (CPU and memory)
• [ ] automountServiceAccountToken: false on pods that don’t need API access

Network Security:

• [ ] Default-deny NetworkPolicy applied to all production namespaces
• [ ] Explicit allow rules for only required connections
• [ ] CNI plugin that enforces NetworkPolicy is installed (Calico, Cilium)
• [ ] Ingress controller configured with TLS

Secret Management:

• [ ] Secrets encrypted at rest in etcd (or External Secrets Operator in use)
• [ ] No secrets in container environment variables (use volume mounts)
• [ ] No secrets in Dockerfile or application code
• [ ] Secret rotation policy defined and automated

Image Security:

• [ ] All images scanned for vulnerabilities (Trivy in CI pipeline)
• [ ] Images signed with Cosign/Sigstore
• [ ] :latest tag disallowed in production (Kyverno policy)
• [ ] Only approved registries allowed (Kyverno policy)
• [ ] Distroless or minimal base images preferred

Monitoring and Audit:

• [ ] Kubernetes audit logging enabled and shipped to central log store
• [ ] Falco or equivalent runtime threat detection installed
• [ ] Prometheus + Grafana monitoring cluster health metrics
• [ ] Alerts configured for: node NotReady, pod crash loops, high resource usage

KubeSphere vs Rancher vs OpenShift: Security Comparison

	KubeSphere	Rancher	OpenShift (OKE)
License	Apache 2.0 (open source)	Apache 2.0 (open source)	Commercial (Red Hat)
Multi-tenancy	✅ Workspace isolation	✅ Project isolation	✅ Project isolation
RBAC UI	✅ Built-in	✅ Built-in	✅ Built-in
Network policy UI	✅ Yes	✅ Yes	✅ Yes
Built-in image scanning	Via extension	Via NeuVector	✅ Built-in (Clair)
Audit logging	✅ Built-in	Via Rancher Logging	✅ Built-in
2FA	Enterprise edition	✅ Yes	✅ Yes
FIPS compliance	Enterprise edition	Limited	✅ Yes
Best for	Multi-tenant Kubernetes, APAC teams	Multi-cluster management	Enterprise, regulated industries

Common Misconfigurations and How to Fix Them

Misconfiguration	Risk	Fix
Container running as root	Full host compromise if escaped	Set runAsNonRoot: true + runAsUser: 1000
No resource limits set	Noisy neighbor, DoS	Set resources.limits on all containers
Default service account mounted	API access from any pod	Set automountServiceAccountToken: false
No network policies	Lateral movement on compromise	Add default-deny + explicit allow rules
Secrets in environment variables	Visible in kubectl describe pod	Mount secrets as files instead
:latest image tag	Unpredictable deployments, untested images	Pin to image:sha256:abc123...
Privileged containers	Full host access	Remove privileged: true, drop capabilities
API server on public internet	Brute force, credential stuffing	Restrict to VPN or private network

Next Steps

With KubeSphere installed and Kubernetes hardened:

• Container-level security — the same principles in this guide extend to standalone Docker deployments covered in our Docker Container Security Best Practices guide — many controls are identical across both environments
• Centralized monitoring — add your Kubernetes cluster to the Prometheus + Grafana monitoring stack by deploying kube-prometheus-stack for cluster-level metrics
• Log aggregation — ship Kubernetes audit logs and pod logs to Grafana Loki using Fluent Bit as a DaemonSet — KubeSphere’s built-in Fluent Operator makes this a one-click installation
• Run Docker and Kubernetes side by side — if your team runs both containerized workloads on Docker and Kubernetes, start with the Docker setup on Ubuntu 26.04 guide before graduating to Kubernetes