Cheat notes · Module 09 · Operate with teams

AppProjects and RBAC: team boundaries

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

Two fences per team: an AppProject decides what Argo CD may deploy for them (from which repos, into which namespaces, which kinds), and Argo CD RBAC decides what a person may do in Argo CD. Namespaces belong to the platform.

Remember

AppProject: sourceRepos, destinations (cluster plus namespace), clusterResourceWhitelist (cluster-scoped kinds allowed) and namespaceResourceBlacklist (namespaced kinds denied). Anything outside fails with not permitted in project.
Argo CD RBAC: policy.csv lines p, role, resource, action, project/app, allow and g, account-or-group, role. Failure: permission denied.
Kubernetes RBAC is the third fence, for kubectl. Failure: forbidden.
Platform-owned namespaces: teams deploy into namespaces they cannot create, label or delete, so CreateNamespace goes away for team apps.
The default project allows everything. In production restrict it (sourceRepos: []) and map SSO groups instead of local accounts.
Also in projects: project roles issue tokens for automation in one project; sync windows allow or deny syncs on a schedule.

Pitfalls

Changing bootstrap/root.yaml and expecting it to apply: root does not manage itself. Apply it by hand.
A team adding a ClusterRole or a NetworkPolicy in its own repo: the sync fails as not permitted and nothing is applied. Access requests go to the platform repo, under review; grant the narrowest thing (view in their namespaces).
"Just admin in dev": the habits a team forms in dev come with it to prod. Give dev a looser project if needed, but keep the fence.

Commands

`argocd proj list`	Every AppProject
`argocd app list -o wide`	Applications with their project
`argocd account can-i sync applications 'PROJECT/*'`	Would Argo CD RBAC allow this?
`kubectl auth can-i list pods -n NS --as USER --as-group GROUP`	Test Kubernetes RBAC as someone else
`kubectl apply -n argocd -f bootstrap/root.yaml`	Root's own file changed: apply it by hand

A team role in policy.csv

p, role:checkout-team, applications, get, checkout/*, allow
p, role:checkout-team, applications, sync, checkout/*, allow
p, role:checkout-team, applications, action/*, checkout/*, allow
p, role:checkout-team, logs, get, checkout/*, allow
p, role:checkout-team, projects, get, checkout, allow
g, checkout-dev, role:checkout-team

Test yourself

Answer in your head first, then open the answer.

checkout-dev runs argocd app delete checkout-prod. Which fence stops it?

Argo CD RBAC: its role has get, sync, actions and logs only.

team-checkout adds a NetworkPolicy to its namespace through Git. What happens?

Argo CD refuses to sync it: NetworkPolicy is on the project's namespace blacklist.

Why do namespaces belong to the platform team?

Labels, quotas and policies on the namespace are the platform's guarantees. A team must not be able to remove them.

not permitted in project versus permission denied: which fence said each?

The AppProject (what may be deployed) versus Argo CD RBAC (what a person may do).

Where module 09 leaves you: Platform apps sit in the platform project, checkout apps in the checkout project (its two repos and two namespaces only). The platform team creates the namespaces. The account checkout-dev can see, sync and read logs for checkout, and nothing else.