Argo CD / Desired state and evidence foundations / Lesson 4

AppProjects and destination boundaries

Review source repositories, destinations, resource kinds, and actual Kubernetes authority together.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain what an AppProject constrains and what it does not replace.
Assess control-namespace and cluster-scoped consequences before accepting source changes.

A project is a policy boundary for Applications

An AppProject groups Applications and can constrain permitted source repositories, destinations, and resource kinds under its documented configuration. It can also carry project roles and related policy. Parcel’s project should express its intended delivery scope rather than inheriting a broad default without review. A project name is not an independent physical isolation boundary. The Argo CD service identity, Kubernetes authorization, repository access, and who can edit the project or Application still determine practical authority. Review the complete path from source writer to target operation.

Read a deliberately narrow example

The AppProject illustration below permits one synthetic repository, one destination namespace, and two namespaced kinds. It has no allowed cluster-scoped kinds in the displayed list. The document is never applied and does not establish that the destination credential is similarly restricted. A real project must account for every required generated kind and actual policy semantics for the installed release. Adding a wildcard to silence a denial changes the trust contract; first determine which source generated which resource and whether that operation belongs to the project.

yaml A synthetic project-scope illustration

apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
  name: parcel-lab
  namespace: argocd
spec:
  sourceRepos:
    - https://example.invalid/parcel-config.git
  destinations:
    - server: https://kubernetes.default.svc
      namespace: parcel-lab
  clusterResourceWhitelist: []
  namespaceResourceWhitelist:
    - group: apps
      kind: Deployment
    - group: ""
      kind: Service

The repository is nonworking teaching input and no object is created. This is not a complete tenancy design, Kubernetes role definition, or evidence that another Application cannot affect the target.

The control namespace deserves special review

Allowing a source to manage the Argo CD control namespace can let it alter sensitive configuration or control objects, depending on permissions and resource scope. A tenant project should not receive that capability merely because it needs its own application namespace. Cluster-scoped resources also cross ordinary namespace boundaries. Review generated namespaces and kinds before accepting a project expansion. A source repository can be an authority channel because the controller acts on its generated instructions, even when the source writer never receives a direct cluster credential.

Evaluate source and target conditions together

The complete local model below requires an allowed source, namespace, and kind tuple. It rejects an otherwise plausible resource in another namespace and an unapproved kind. It is not an AppProject parser or Argo CD authorization implementation: real rules include supported patterns, deny behavior, roles, and cluster identity. The model shows why checking only repository identity is insufficient. Actual policy facts must come from reviewed configuration, not a statement inside the repository that declares itself trusted.

python A synthetic combined-scope predicate

allowed_source = "parcel-config-lab"
allowed_kinds = {("apps", "Deployment"), ("", "Service")}
def permitted(source, namespace, kind):
    return source == allowed_source and namespace == "parcel-lab" and kind in allowed_kinds
print(permitted("parcel-config-lab", "parcel-lab", ("apps", "Deployment")))
print(permitted("parcel-config-lab", "argocd", ("apps", "Deployment")))
print(permitted("parcel-config-lab", "parcel-lab", ("", "Secret")))

Expected output

True
False
False

The program evaluates declared strings and tuples only. It neither reads an AppProject nor tests Kubernetes RBAC or a real Argo CD policy decision.

Policy editing is high-authority work

A restricted project is useful only when its definition and role bindings are protected appropriately. Someone able to broaden source or destination rules can change the controller’s delegated authority. Keep source review, Application editing, project administration, and target credential ownership explicit. A denial may be correct evidence that a proposed change exceeds the approved contract. Diagnose the requested resource and policy layer before changing access. Retain a bounded explanation for any legitimate expansion, including why narrower alternatives do not satisfy the actual requirement.

Common errors and fixes

A denied generated kind leads to a wildcard project rule.

Why it happens: A specific policy observation was treated as a reason to remove the boundary.
How to fix it: Identify the resource and review a narrow justified scope change if required.
Prevent it next time: Keep project changes attributable and independently reviewed.

A namespaced destination is assumed to prevent every cluster-level effect.

Why it happens: Namespace context was confused with resource scope and credential authority.
How to fix it: Review generated cluster-scoped kinds and actual Kubernetes permissions.
Prevent it next time: Assess the complete source-to-controller-to-target path.

A tenant can edit the project that constrains its own Application.

Why it happens: Policy administration shares the same trust boundary as the constrained source.
How to fix it: Protect project and role changes through appropriate independent authority.
Prevent it next time: Review who can broaden each policy layer.

Check your understanding

1. The repository is allowed but emits a Secret that the narrow example excludes. Should the project automatically widen?

Show worked solution

No. Identify the requirement and ownership, review secret-management design, and decide whether a narrow policy change is authorized. Source inclusion alone does not approve every generated kind. A correct denial is useful evidence.

2. Why review access to the Argo CD namespace separately from parcel-lab?