◇ OpenCyber Academy
Technologist · Chapter 7 · English

Chapter 7 — Identity and access foundations

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 7 — Identity and access foundations

Lesson map

Lesson 07 published. Map, example, EX019.

flowchart TD
  N0["Learning outcomes"]
  N1["7.1 Who and what"]
  N2["7.2 Least privilege"]
  N3["7.3 Kubernetes RBAC"]
  N4["7.4 Service accounts"]
  N5["7.5 Leavers"]
  N6["7.6 Multi-factor authentication"]
  N7["Reviewing access regularly"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX019"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["7.1 Who and what"]
  N2["7.2 Least privilege"]
  N3["7.3 Kubernetes RBAC"]
  N4["7.4 Service accounts"]
  N5["7.5 Leavers"]
  N6["7.6 Multi-factor authentication"]
  N7["Reviewing access regularly"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX019"]

[Learning outcomes]
    |
    v
[7.1 Who and what]
    |
    v
[7.2 Least privilege]
    |
    v
[7.3 Kubernetes RBAC]
    |
    v
[7.4 Service accounts]
    |
    v
[7.5 Leavers]
    |
    v
[7.6 Multi-factor authentication]
    |
    v
[Reviewing access regularly]
    |
    v
[Worked example] --> [Exercise EX019]

Learning outcomes

You will (1) explain authentication and authorisation; (2) apply least privilege; (3) describe roles in cloud and Kubernetes.

7.1 Who and what

Authentication confirms who someone is; authorisation decides what they may do. In cloud systems, identities include people, services and automation such as the CI bot. Priya keeps a list of identity types for each cluster: staff accounts such as Kwame's and her own, service accounts used by workloads, and automation such as the CI bot that deploys new versions. Each of these identity types needs a different kind of review. Staff accounts are checked against the staff list, service accounts against the workloads that use them, and automation against the jobs it actually performs.

7.2 Least privilege

Each identity should have only the access it needs. Sandhu et al. (1996) describe role-based access control, where permissions are grouped into roles and roles assigned to users, making least privilege easier to manage. In practice, least privilege at Cobalt means asking what each identity does, then granting exactly those actions. The CI bot deploys workloads, so it needs rights to manage deployments, not to create role bindings or read every secret. Roles make this manageable: instead of setting permissions per account, the team defines a deployer role once and binds it to whichever automation needs it.

7.3 Kubernetes RBAC

Kubernetes uses Roles and ClusterRoles to grant actions on resources, bound to users or service accounts. A ClusterRoleBinding to cluster-admin grants everything and should be rare. A Role grants actions inside one namespace, while a ClusterRole can grant actions across the whole cluster. The difference matters at Cobalt because several smaller clients share one cluster; a Role confined to one client's namespace cannot touch another's workloads. Bindings are where mistakes hide, since a single binding to cluster-admin outweighs every careful Role. Priya's monthly export therefore lists bindings, not only role definitions.

7.4 Service accounts

Workloads run with service accounts. The default service account should have no extra permissions; each workload that needs API access gets its own account. If several workloads share one service account, a compromise of any of them gains the access of all, and audit logs cannot say which workload made a request. Separate accounts keep access narrow and make the logs useful. Priya checks the shared cluster's namespaces and records which workloads use the default account; those that do not call the Kubernetes API keep it, with its permissions left empty.

7.5 Leavers

When staff leave, their access must be removed. Priya finds an account called old-admin still active on one cluster. The old-admin account shows how leavers' access survives: the account was created on client-b long ago and never appeared in any list that was checked when its owner left. Priya proposes a leaver step for every cluster, so removing someone from the staff directory also prompts a check of cluster bindings. The monthly cluster-admin review then catches anything that the leaver step misses.

7.6 Multi-factor authentication

Console access for staff requires a second factor, which greatly reduces the impact of stolen passwords. A password alone can be phished, guessed or reused from another breach; a second factor means the password is not enough on its own. For Cobalt the console is the most powerful access staff hold, since it can change settings outside the pipeline. Priya confirms that every staff console account at Cobalt has a second factor enabled and records any exception with an owner.

Reviewing access regularly

Kwame's team now reviews cluster-admin holders every month. The review takes ten minutes: export the bindings, compare with the staff list, and remove anything unexplained. Priya automates the export so the review only needs a person for the judgement, not the collection of data.

Shared accounts

Shared logins hide who did what. Each person at Cobalt now has an individual account, so audit logs name a real person.

Worked example

Priya lists who has cluster-admin on the client-b cluster: Kwame, the CI bot and old-admin. Kwame confirms old-admin belonged to a former employee. They remove it the same day, and Priya notes that the CI bot needs only deployment rights, not cluster-admin.

Synthetic case. Accounts are synthetic.

Errors and limits

Removing access can break automation that silently used it; test after changes.

Exercises

Synthesis

Give each identity only what it needs and remove what is no longer used.

Continue studying — chapter 07 of 30

← Chapter 06 (draft) · Course chapter index · Chapter 08 (draft) →