Sure shot question 10: RBAC - Implementing Fine-Grained Access Control in Kubernetes: Restricting a ServiceAccount to Create Secrets and ConfigMaps

Question Format

 

Create a new ServiceAccount gitops in Namespace project-1.

Create a Role and RoleBinding, both named gitops-role and gitops-rolebinding as well. These should allow the new SA to only create Secrets and ConfigMaps in that Namespace.

 

Prerequisites

A Kubernetes cluster with RBAC enabled.

kubectl configured to interact with the cluster.

The project-1 namespace (created automatically if it doesn’t exist).

 

Step 1: Create the ServiceAccount

Create a ServiceAccount named gitops in the project-1 namespace:

kubectl create serviceaccount gitops -n project-1

Verify the ServiceAccount:

kubectl -n project-1 get serviceaccounts

 

Step 2: Define the Role

Create a Role named gitops-role that grants permissions to create Secrets and ConfigMaps.

Create a file named gitops-role.yaml:

yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
 name: gitops-role
 namespace: project-1
rules:
- apiGroups: [""]           # Core API group (for Secrets/ConfigMaps)
 resources: ["secrets", "configmaps"]
 verbs: ["create"]         # Only allow creation (no get, list, or delete)

Apply the Role:

kubectl apply -f gitops-role.yaml

Verify the Role:

kubectl -n project-1 get roles

 

Step 3: Bind the Role to the ServiceAccount

Create a RoleBinding named gitops-rolebinding to link the Role to the ServiceAccount.

Create a file named gitops-rolebinding.yaml:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
 name: gitops-rolebinding
 namespace: project-1
subjects:
- kind: ServiceAccount
 name: gitops              # Name of the ServiceAccount
 namespace: project-1      # Namespace of the ServiceAccount
roleRef:
 kind: Role
 name: gitops-role         # Name of the Role
 apiGroup: rbac.authorization.k8s.io

Apply the RoleBinding:

kubectl apply -f gitops-rolebinding.yaml

Verify the RoleBinding:

kubectl -n project-1 get rolebindings

 

Step 4: Test the Permissions

 

4.1 Verify Access to Create Secrets

Test if the gitops ServiceAccount can create a Secret in project-1:

kubectl -n project-1 create secret generic test-secret 

 --from-literal=key=value 

 --as=system:serviceaccount:project-1:gitops

Expected output:

secret/test-secret created

 

4.2 Verify Access to Create ConfigMaps

Test if the gitops ServiceAccount can create a ConfigMap:

kubectl -n project-1 create configmap test-config 

  --from-literal=key=value 

 --as=system:serviceaccount:project-1:gitops

Expected output:

configmap/test-config created

 

4.3 Test Unauthorized Actions

 

The ServiceAccount should not have permissions to list or delete resources.

kubectl -n project-1 get secrets \  --as=system:serviceaccount:project-1:gitops

Expected output:

Error from server (Forbidden): secrets is forbidden: User "system:serviceaccount:project-1:gitops" cannot list resource "secrets" in API group "" in the namespace "project-1"

 

Troubleshooting

Permission Denied:

Ensure the Role’s verbs and resources match the intended actions.

Confirm the RoleBinding references the correct Role and ServiceAccount.

Namespace Mismatch:

Verify all resources (Role, RoleBinding, ServiceAccount) are in project-1.