Module 9 Lesson 4: Auditing & User Access

DevOps is about "Speed," but security is about Control. You need to know exactly who has the power to "Push to Production."

1. The RBAC Model (Roles)

GitLab uses Role-Based Access Control:

• Guest: Can see issues.
• Reporter: Can see code.
• Developer: Can push branches and trigger non-protected pipelines.
• Maintainer: Can push to main and trigger production deployments.
• Owner: Full control over settings and billing.

---

2. Protected Branches & Tags

To prevent a junior developer from accidentally "Deleting Production":

1. Go to Settings -> Repository -> Protected branches.
2. Restrict main so that only Maintainers can push or merge.
3. This forces everyone else to go through a Merge Request (and a Quality Gate!).

---

3. Audit Events (The "Black Box")

Found under Secure -> Audit Events.

• It logs every "Critical" action: users being added, variables being changed, project settings being modified.
• Immutable: These logs cannot be deleted by a project Maintainer. They are the "Single Source of Truth" for an investigation.

---

4. IP Allow-listing

For high-security companies, you can restrict GitLab access so it only works if current user is on the Company VPN. Any request from a "Foreign" IP is blocked automatically.

---

Exercise: The Access Audit

1. Go to your project -> Manage -> Members.
2. Give a friend "Developer" access. Can they change the "Protected Branch" settings?
3. Find your Audit Events. Who was the last person to add a CI/CD variable?
4. Why is the "Least Privilege" principle (giving people only the minimum access they need) the #1 rule of security?
5. Search: What is a "Group SAML" integration?

---

Summary

IAM and Auditing are the "Paper Trail" of your DevOps machine. By carefully managing roles and watching the audit logs, you ensure that your automation power is used only by those you trust, in the way you intended.

Next Lesson: Hardening the engine: Hardening the Runner Environment.