Implementing Role-Based Access Control for Secrets

In this lesson, you will learn how to tighten your security posture by implementing granular Role-Based Access Control (RBAC) to ensure that only authorized users or services can access your sensitive Secret resources.

Why RBAC for Secrets?

By default, if a user has broad permissions, they might be able to list or view all Secrets in a namespace. This is a significant security risk. Following the principle of least privilege, we want to restrict access so that, for example, a specific ServiceAccount used by your backend application can only get or list the specific Secrets it requires to function, while developers might only have read access to non-production Secrets.

Defining Granular Access

To implement this, we define a Role (scoped to a namespace) that explicitly lists the resources and the actions (verbs) allowed. Here is how you might grant a service account read-only access to a single specific secret:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["db-credentials"] # Restrict to a specific secret
  verbs: ["get", "list"]

After creating the Role, you must bind it to the target identity (the ServiceAccount) using a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-db-secret
  namespace: production
subjects:
- kind: ServiceAccount
  name: app-backend
  namespace: production
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Best Practices

• Target specific resources: By using the resourceNames field, you prevent a ServiceAccount from reading every secret in the namespace, limiting the blast radius if the application is compromised.
• Avoid wildcard verbs: Never use verbs: ["*"]. Always explicitly define what is needed, such as get or watch.
• Audit Regularly: Use your knowledge of auditing resource usage to check if these roles are actually being utilized or if they are overly permissive.

Key Takeaway: You can minimize the risk of credential leakage by using RBAC Roles and RoleBindings to restrict Secret access to the minimum set of identities and specific resources necessary for your application to function.