Homework

Objective

Extend the lab chart to support both namespace-scoped Roles and cluster-scoped ClusterRoles, controlled through values.yaml.

Instructions

1. Add a new value rbac.clusterWide: false to values.yaml.
2. Create a new template templates/clusterrole.yaml that renders a ClusterRole when rbac.create and rbac.clusterWide are both true.
3. Create a corresponding templates/clusterrolebinding.yaml.
4. Modify templates/role.yaml and templates/rolebinding.yaml to only render when rbac.clusterWide is false.
5. Add a second set of rules in values for the cluster-wide scenario:

   rbac:
     create: true
     clusterWide: false
     rules:
       - apiGroups: [""]
         resources: ["configmaps", "secrets"]
         verbs: ["get", "list", "watch"]
     clusterRules:
       - apiGroups: [""]
         resources: ["namespaces", "nodes"]
         verbs: ["get", "list"]
       - apiGroups: [""]
         resources: ["configmaps"]
         verbs: ["get", "list", "watch"]

6. Validate with helm template using both --set rbac.clusterWide=true and --set rbac.clusterWide=false.

Deliverable

The rendered output from both scenarios. Verify that:

• With clusterWide=false: only Role + RoleBinding are rendered
• With clusterWide=true: only ClusterRole + ClusterRoleBinding are rendered

Objective

Configure a ServiceAccount with image pull secrets for a private container registry, and verify that pods automatically inherit the credentials.

Instructions

1. Create a Docker registry secret in your cluster:

   kubectl create secret docker-registry my-registry-creds \
     --docker-server=https://ghcr.io \
     --docker-username=YOUR_USERNAME \
     --docker-password=YOUR_TOKEN \
     -n rbac-lab

2. Update values.yaml to include the image pull secret on the ServiceAccount:

   serviceAccount:
     create: true
     imagePullSecrets:
       - name: my-registry-creds

3. Deploy the chart and verify the ServiceAccount has the pull secret attached:

   kubectl get serviceaccount configreader -n rbac-lab -o yaml

4. Verify that a pod using this ServiceAccount automatically inherits the pull secret by inspecting the pod spec:

   kubectl get pod <pod-name> -n rbac-lab -o jsonpath='{.spec.imagePullSecrets}'

Deliverable

Screenshots or terminal output showing:

• The ServiceAccount YAML with imagePullSecrets populated
• The pod spec showing the inherited pull secrets

Objective

Given an intentionally over-permissioned RBAC configuration, identify the security issues and produce a hardened version.

The Problematic Configuration

An application only needs to read ConfigMaps in its own namespace, but was deployed with these RBAC rules:

# INSECURE - do not use in production
rbac:
  create: true
  clusterWide: true

# ClusterRole with excessive permissions
clusterRules:
  - apiGroups: ["*"]
    resources: ["*"]
    verbs: ["*"]

serviceAccount:
  create: true
  automount: true

Instructions

1. List every security problem with the configuration above (aim for at least 5 issues).
2. Write a hardened values.yaml that follows least-privilege for an app that only reads ConfigMaps in its namespace.
3. Deploy both versions (insecure and hardened) and compare the output of:

   kubectl auth can-i --list \
     --as=system:serviceaccount:<namespace>:<sa-name> \
     -n <namespace>

4. Write a brief report (200-300 words) explaining the risks of the original configuration and how your hardened version addresses each one.

Deliverable

A table listing the issues found and how each was fixed:

Plus the hardened values.yaml and the kubectl auth can-i --list comparison output.