Separating git repository access and policy

[squaremo]

The GitRepository type gives both access to a git repository and a policy for using it. This scheme has the benefit of having few kinds of object to think about, but does have some downsides:

• if you want to use a git repository for several syncs, but you want to vary the versions synced independently (e.g., to lock one at a specific version), you must set up several GitRepository objects, either in anticipation, or at the point the versions diverge;
• if the means of access to a git repository (e.g., credentials) changes, you might have to change it in several places;
• you cannot divide permissions between providing access to a git repository, and being able to set the version;
• for the purpose of automation, only the means of access to a git repository is needed, and not the ability to download a tarball at a particular version, making GitRepository a square peg in a triangular hole.

This suggests it might be useful to separate the means of access to a git repository from the policy for using it. The policy would be the source, used by kustomizations and so on.

It introduces an extra kind of object to deal with, and thus an extra step when setting things up (though it can probably be smoothed over in the user interface). In mitigation of that, git access mostly doesn't need to be altered once set up, with policies getting most of the attention.

[stefanprodan]

if the means of access to a git repository (e.g., credentials) changes, you might have to change it in several places;

Credentials are stored in a secret that can be shared between multiple GitRepositories, changing the secret once will make it apply to all repos.

for the purpose of automation, only the means of access to a git repository is needed, and not the ability to download a tarball at a particular version, making GitRepository a square peg in a triangular hole.

A GitRepository can be created with spec.suspend: true and source-controller will not act on it.

You have valid point about duplicating the repos per version but I think it's a good tradeoff compared to the alternative of adding a 2nd type to all the source kinds.

[squaremo]

You have valid point about duplicating the repos per version but I think it's a good tradeoff compared to the alternative of adding a 2nd type to all the source kinds.

I'm not proposing adding a policy type for all the source kinds -- just for git repository. (You already have HelmRepository and HelmChart, which separate access and policy).

[squaremo]

A GitRepository can be created with spec.suspend: true and source-controller will not act on it.

Sure, I know it can be made to work; the question is do you want people to work with source-controller or work around source-controller? At present, it feels like it's not designed to be used by other systems -- it's compatible with what image update automation needs, but that coincidence could evaporate.

[squaremo]

I don't think this has to be considered urgently, since it won't stop image automation and other things from making progress -- I would peg it as something to think about when reviewing the API.

[hiddeco]

you cannot divide permissions between providing access to a git repository, and being able to set the version;

Looking at #107 (comment), it may be a better option to introduce an optional field to the ImageUpdateAutomation object, that allows a user to configure non read-only credentials that take precedence over the credentials from the GitRepository it refers to.

[squaremo]

I did consider having an entirely separate type, since none of the source-controller machinery is actually necessary, just the details for accessing the repository. That's still an option, if the answer ultimately is "GitRepository is not for that".

[hiddeco]

Sure, but then why not just include the URL there too? There's no other things the automation controller needs from a git repository.

There are a couple of reasons I can think of:

• No hierarchical order and/or relationship between the objects, while from a human perspective, they likely are coupled.
• No "safety net" that stops automation if the GitRepository is removed from the cluster, as there will no longer be any API calls to confirm existence.
• For the group of people that do not have separate credentials, it will be more cumbersome to setup automation.

[squaremo]

you cannot divide permissions between providing access to a git repository, and being able to set the version;

Looking at #107 (comment), it may be a better option ...

The scenario I had in mind with that point was this: you have two teams and want to be able to organise it so the operations team will set up access to the git repositories, and the apps team chooses which versions get deployed.

[stefanprodan]

The scenario I had in mind with that point was this: you have two teams and want to be able to organise it so the operations team will set up access to the git repositories, and the apps team chooses which versions get deployed.

We will allow this scenario with the multi-tenancy setup described in #263:

Workflow:

• ops-team bootstraps the fleet-infra repo
• ops-team sets up the dev-team-infra repo reconciliation in the fleet-infra (GitRepository+Kustomization+Namespaces+RBAC)
• dev-team adds their apps repos to the dev-team-infra repo using a GitRepository+Kustomization per app
• kustomize-controller impersonated the dev-team user (restricted to the namespaces configured for dev-team-infra) when reconciling the apps

The dev-team has full control on their own namespaces, they can add GitRepositories and setup reconciliation without cluster admin intervention.

ops-team

# boostrap staging cluster with multi-tenancy enabled
gotk bootstrap github --repository=fleet-infra --path=staging --multi-tenancy

git clone github.com/org/fleet-infra

# create namespace and roles with restricted access
gotk create tenant dev-team --with-namespace=app1 --export > ./staging/app1.yaml
gotk create tenant dev-team ---with-namespace=app2 --export > ./staging/app2.yaml

# add the dev team repo 
gotk create source git dev-team --url=https://github.com/org/dev-team-infra --branch=staging --export > ./staging/dev-team-repo.yaml
gotk create kustomization dev-team --source=dev-team --export > ./staging/dev-team-sync.yaml

# push tenant definition
git add -A && git commit && git push

dev-team

git clone github.com/org/dev-team-infra
git checkout staging

# add app1 (plain yamls)
gotk -n app1 create source git app1 --url=https://github.com/org/app1 --branch=main --export > app1-repo.yaml
gotk -n app1 create kustomization app1 --source=app1 --export >  app1-sync.yaml

# add app2 (helm chart)
gotk -n app2 create source helm apps-repo --url=https://org.github.io/charts --export > helm-repo.yaml
gotk -n app2 create helmrelease app2 --source=apps-repo --export > app2-release.yaml

# push app definitions for the staging cluster
git add -A && git commit && git push

[squaremo]

That's not the same scenario. If it were, the dev-team would be able to create Kustomization objects, but not GitRepository objects. The aim is to restrict them to syncing only their own git repository, while letting them decide how the syncing is done.

It may be that this isn't a useful aim, or that it won't work for some reason. But assuming neither of those is the case, the transcript above allows the dev team to add arbitrary git repositories, so doesn't meet the aim.