Kubernetes Security Best Practices: RBAC, Secrets & Pod Security

Kubernetes security best practices start by limiting what identities can do, protecting credentials, restricting what workloads may do on a node, and exposing only the network paths the application actually needs.

For small teams, the goal is not to reproduce every enterprise security control. It is to establish a baseline that prevents a routine application compromise from turning into cluster-wide control. RBAC should follow least privilege, workloads should use purpose-specific ServiceAccounts, Secrets should have a deliberate storage and delivery model, and Pods should run under a security policy appropriate to their risk.

This guide owns the security baseline inside the Kubernetes Cluster Management for Small Teams operating model. It does not duplicate the traffic-isolation work in Kubernetes Network Policies for Small Teams or the tenant-architecture decisions in Kubernetes Multi-Tenancy for MSPs.

At Raff, the security review starts with one question: if this identity, Pod, or credential is compromised, what is the largest action it can perform next? The baseline should make that answer as narrow and explainable as the workload allows.

Kubernetes security starts with four control layers

A production Kubernetes security baseline is easier to operate when controls are separated by what they protect.

These layers are related but not interchangeable.

RBAC can prevent a ServiceAccount from deleting Deployments, but it does not stop the application process from running as root inside its container. Pod Security can restrict privilege escalation, but it does not decide whether an engineer may read a Secret. A private VPC reduces public exposure, but it does not make every Pod inside the cluster equally trusted.

The operating model is therefore layered:

Human / workload identity
        ↓
Kubernetes RBAC
        ↓
Secret and credential access
        ↓
Pod execution restrictions
        ↓
Network exposure and segmentation
        ↓
Application authorization

Pod Security Standards define what a workload may do on a node; RBAC defines what an identity may do through the Kubernetes API.

For network segmentation after a workload is admitted, use the dedicated Kubernetes NetworkPolicy guide. This page keeps the security baseline centered on identities, credentials, and workload execution.

RBAC should make least privilege the default

Kubernetes Role-Based Access Control authorizes actions against API resources. The most important production rule is to grant only the permissions an identity actually needs.

The official Kubernetes RBAC good practices recommend namespace-level permissions where possible, avoiding wildcard permissions, and minimizing powerful credentials.

The four core RBAC objects have different scopes:

This means a ClusterRole is not automatically a cluster-wide grant. A RoleBinding can bind a ClusterRole within one namespace. The larger escalation happens when a ClusterRole is attached through a ClusterRoleBinding.

A ClusterRoleBinding is a cluster-wide permission decision, not a convenience shortcut.

Small teams should review several permission patterns carefully:

• cluster-admin for routine users, CI/CD, or application workloads;
• wildcard verbs such as * when only get or list is required;
• wildcard resource access that automatically expands to future API resources;
• Secret get, list, or watch permissions;
• permissions to create or modify Pods and workload controllers;
• access to RBAC resources that lets an identity grant new permissions;
• cluster-scoped permissions when the workload operates in one namespace.

One subtle risk is workload creation. Kubernetes documents that permission to create a Pod or a controller such as a Deployment in a namespace can create indirect access to Secrets and other resources available to workloads in that namespace. Security review should therefore consider what an identity can cause a Pod to mount or impersonate, not only which objects it can read directly.

A practical review starts by asking what the identity must do in normal operation, then grants only the verbs, resources, and namespaces required for that job. If an emergency needs broader access, treat that as an explicit administrative path rather than the everyday default.

ServiceAccounts should have one job and minimal credentials

Kubernetes ServiceAccounts are non-human identities used by Pods, controllers, CI/CD systems, and automation.

Every namespace receives a default ServiceAccount. With RBAC enabled, that default identity receives only the baseline discovery permissions unless more access is granted. However, a Pod that does not specify another ServiceAccount is assigned the namespace's default ServiceAccount, and Kubernetes normally projects credentials for the assigned identity into the Pod.

The security baseline is therefore not simply “the default ServiceAccount has no roles.” It is to make workload identity intentional.

Use a dedicated ServiceAccount when a workload needs Kubernetes API permissions. Grant that account only the required RBAC rights and assign it only to the workloads that need them.

When an application does not need to call the Kubernetes API, consider disabling automatic service-account token mounting with automountServiceAccountToken: false. Current Kubernetes versions use short-lived, automatically rotating projected tokens through the TokenRequest API for normal Pod ServiceAccount credentials, which is safer than the older long-lived static token pattern. The Service Accounts documentation recommends short-lived TokenRequest or projected tokens over manually created long-lived ServiceAccount token Secrets.

A small-team identity model can be simple:

web application
  → no Kubernetes API access

deployment controller
  → narrowly scoped deployment permissions

backup controller
  → only the resources required for backup/restore

human administrator
  → separate named administrative identity

Avoid using one powerful ServiceAccount for several unrelated workloads merely because it already works. Shared credentials make it harder to understand blast radius and harder to rotate or revoke one application's access without affecting another.

At Raff, we treat a ServiceAccount as part of the workload architecture, not as deployment boilerplate. If a Pod receives an API credential, there should be a named reason for it.

Secrets need stronger controls than base64 encoding

Kubernetes Secrets provide a native way to hold confidential values such as passwords, tokens, keys, or certificates, but the object type does not make every secret-handling decision safe automatically.

The most important distinction is that base64 is formatting, not encryption.

The upstream Kubernetes Secrets documentation states that Secret objects are stored unencrypted in etcd by default unless encryption at rest is configured. Managed Kubernetes services can change that implementation detail, so teams should verify the provider's documented behavior rather than assuming upstream defaults or assuming encryption exists without evidence.

For Raff specifically, the current public Kubernetes product page does not document the encryption-at-rest implementation for Kubernetes Secret objects. This guide therefore does not claim one. Teams with a specific encryption or key-management requirement should verify that control before treating it as part of their compliance boundary.

Secret security still has several workload-level controls regardless of provider implementation:

• do not commit plaintext Secret values to Git or application repositories;
• restrict RBAC access to get, list, and watch Secrets;
• separate namespaces when workloads should not share mounted-secret trust;
• expose each workload only to the credentials it actually needs;
• rotate credentials when a team member, service, or integration no longer needs them;
• avoid logging Secret values or passing them through diagnostics;
• use short-lived credentials where the external system supports them;
• define who can create workloads that mount or reference Secrets.

The Kubernetes Secrets good practices also recommend encryption at rest and restrictive Secret API permissions for cluster administrators.

Raff currently lists Sealed Secrets as an optional one-click Kubernetes application. That can be part of a team's Git-oriented Secret workflow, but its availability should not be interpreted as automatic Secret encryption for every workload or as a replacement for RBAC and credential rotation.

The practical question is not “Are we using Kubernetes Secrets?” It is “Who can retrieve this value, how does the workload receive it, how is it rotated, and what happens if it leaks?”

Pod Security Standards create a workload execution baseline

RBAC protects the Kubernetes API. Pod security controls what an admitted workload can do once it runs on a node.

Kubernetes defines three Pod Security Standards:

The Restricted profile builds on Baseline and includes controls such as disallowing privilege escalation, requiring non-root execution, requiring an allowed seccomp profile, and dropping Linux capabilities except tightly defined exceptions.

This does not mean every namespace should be switched directly to Restricted without testing. Infrastructure components, storage systems, networking add-ons, or other trusted system workloads can require privileges that ordinary applications should never receive.

Kubernetes' built-in Pod Security Admission supports three modes:

• enforce rejects Pods that violate the selected policy;
• audit records violations in audit annotations without rejecting the Pod;
• warn shows a user-facing warning while allowing the Pod.

These modes make gradual adoption possible. A team can identify which workloads fail a target policy before turning that policy into a production admission gate.

Workload securityContext settings then provide the concrete execution controls beneath that policy. Common production settings to evaluate include:

• runAsNonRoot;
• allowPrivilegeEscalation: false;
• dropping unnecessary Linux capabilities;
• using RuntimeDefault or another approved seccomp profile;
• avoiding privileged containers and host namespace access unless the workload requires them.

The correct policy follows the workload. A normal public API should not receive host-level privileges because one monitoring or storage component requires them.

The security decision framework should follow workload risk

A small team does not need one identical policy for every Pod. It needs explicit security tiers whose exceptions can be explained.

Use four questions when approving an exception:

1. Why does this workload need the permission or privilege? Name the feature that fails without it.
2. Can the permission be namespaced? Avoid cluster-wide grants when the workload operates in one namespace.
3. Can the credential be removed or shortened? A workload that never calls the API should not carry an API token by habit.
4. What is the blast radius if the workload is compromised? Consider API access, mounted Secrets, node privileges, and network reachability together.

Network isolation remains a separate layer. If the answer includes “this Pod should only talk to the database and DNS,” implement that through the NetworkPolicy model, not through RBAC.

For MSPs deciding whether a tenant should share a control plane at all, use Kubernetes Multi-Tenancy for MSPs. That page owns the shared-cluster-versus-dedicated boundary.

Raff secures the platform boundary while workload controls stay yours

Raff Managed Kubernetes reduces the infrastructure-security surface a small team has to operate directly. Raff currently runs and monitors the Kubernetes masters, etcd, and platform networking. Every cluster receives its own VPC, worker nodes sit on the private network, and a managed public endpoint provides the deliberate inbound edge.

The standard managed control plane is currently $0/month, so using a managed control plane does not add a separate control-plane fee. That can remove self-managed control-plane patching and availability work from the application team's day-to-day scope.

The workload boundary remains explicit:

Raff's current Kubernetes page also states that the dashboard lets you download a kubeconfig with full cluster-admin access. Treat that credential as highly privileged. Limit who receives it, avoid embedding it into routine application automation, and create narrower identities for everyday workflows where your cluster design supports them.

This is an important distinction: Raff account-level IAM, MFA, and audit history protect actions at the cloud-platform layer; they should not be described as a replacement for in-cluster Kubernetes RBAC or Kubernetes API audit policy.

Likewise, a private VPC and edge firewall reduce infrastructure exposure but do not decide which ServiceAccount can read a Secret or whether a container can run privileged.

A managed control plane reduces the platform security work you operate; it does not make workload permissions least-privilege automatically.

Review Raff Kubernetes for the current cluster model and Raff Security for the platform-level network, IAM, MFA, and audit controls around Raff resources.

Kubernetes security should become a recurring review cycle

A security baseline loses value when it is applied once and never revisited.

Review the cluster when permissions, workloads, dependencies, or team ownership changes. A practical small-team cadence is:

• Every deployment change: review new privileges, Secret references, public exposure, and security-context exceptions;
• Monthly: review cluster-wide RBAC bindings, powerful ServiceAccounts, unused credentials, and privileged workloads;
• After team or vendor access changes: remove unneeded kubeconfigs, tokens, roles, and automation credentials;
• Before Kubernetes upgrades: verify admission, policy, and workload compatibility with the target version;
• After an incident: review whether the compromised identity or workload had more authority than its normal job required.

Keep the review evidence simple enough to maintain. A table of privileged identities, why they exist, what namespaces they affect, and who owns them is more valuable than a security document nobody updates.

Kubernetes security is strongest when permissions and exceptions are explainable. Use RBAC to narrow API authority, purpose-specific ServiceAccounts to separate workload identities, deliberate Secret handling to reduce credential exposure, and Pod Security Standards to keep ordinary applications away from host-level privilege.

Then layer NetworkPolicy, application authorization, image/update hygiene, monitoring, and recovery around that baseline. The objective is not zero privileges. It is to make every elevated permission a named, reviewable exception instead of an accidental default.

Sources

• Kubernetes RBAC Good Practices
• Kubernetes RBAC Authorization
• Kubernetes Service Accounts
• Kubernetes Secrets
• Good Practices for Kubernetes Secrets
• Kubernetes Pod Security Standards
• Kubernetes Pod Security Admission
• Kubernetes Security Context
• Kubernetes Security Checklist
• Raff Kubernetes
• Raff Security