Harbor: Immutable Repositories

[tschwaller]

As a administrator I would like to make specific repositories (e.g. in production) immutable, since this is a mandatory regulatory requirement in certain industries and has been asked by several customers. This has to be a mechanisms based on tags, e.g. if you push an image (e.g. alpine) to an immutable repository (e.g. harbor.lab.local/tom) with a certain tag (e.g. 3.6), then you can not re-push it again. But you can still create images with another tag (e.g. a new version).

Example:

docker push harbor.lab.local/tom/alpine:3.6

This works, but when you do it a second time you get e.g.:

tag=3.6 cannot be overwritten because tom/alpine is an immutable repository

Pushing an updated version works:

docker push harbor.lab.local/tom/alpine:3.6.1

There should also be an admin option that images in a certain repository can not be deleted anymore (black hole feature: You get an image into a repository, but never out again).

[yixingjia]

degist id to identify tag, will have a lot of issue, need to further discussion.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ghost]

We are also interested in a way to make images immutable, so that you can not push an image with a tag already existing in the registry.

[miguelpoyatosmora]

I am also interested in the diferent options to archive inmutablility on specific harbor images

[annProg]

Is there any progress in this issue? I am also interested about Immutable tag. Like docker-ee DTR: https://docs.docker.com/ee/dtr/user/manage-images/prevent-tags-from-being-overwritten/

[vasicvuk]

+1

[gecube]

I think it will be great feature, because there is another option to implement in on the pipeline's side (in CI/CD process), but it is not fool-proof.

[alxndr13]

+1

[alxndr13]

imo there are two ways to make this happen:

Implement this functionality registry-wide or implement it as a project policy. I just started digging around in the code, but i'm not fluent in Angular.. If theres anyone interested in this, who is capable of writing the Angular part, i can assist doing the go stuff.

[gecube]

@alxndr13 The best solution is to provide policy-like feature. The registry-wide can be implemented too but WE need granularity (i.e. there are production images with version like v.1.0.0, v.1.0.1 etc. which MUST be protected and the common labels like "latest" which will point to the latest release and often are rewritten).

[alxndr13]

@gecube I agree. There should be the possibility to add something like a whitelist of tags, which can be overwritten even tho the "immutable" policy is set.

[rovner]

+1

[strainovic]

+1

[achyutjhunjhunwala]

+1

[airadier]

+1

[urosht]

+1

[noffa]

+1

[chengjingtao]

+1

There are many similar mechanism , like git protected branch or released version of jar.
In common production artifacts, It is a really usefull feature to prevent the released version being changed.
It has some relations to feature of Image Signature, they have a same goal : Makes people to beleve the artifacts is reliable.

I have some different thought about this feature except Immutable Repositories,

• support Immutable Repositories and Immutable Tags.
• match tags by regular expression
• match repositories by it's project

Because single setting of repository is too tedious。

[cd1989]

+1

I'd prefer the project level immutable setting.

[louyiping]

Also meet this issue. We need it. Because if someone override a base image used by others could cause problem.

[michmike]

adding this ticket to the 1.10 pool of candidate stories. i am in full support of this and we can expose it using 3 levers in Harbor under project settings

1. Make an entire project immutable
2. Allow a user to define a regex to include repos that are immutable
3. Allow a user to define a regex to include tags that are immutable

2 & 3 are not mutually exclusive

[xaleeks]

+1

I'd prefer the project level immutable setting.

Is this referring to nothing pushed to any repos in a project can be overwritten. But deletion are still allowed I assume

[xaleeks]

adding this ticket to the 1.10 pool of candidate stories. i am in full support of this and we can expose it using 3 levers in Harbor under project settings

1. Make an entire project immutable
2. Allow a user to define a regex to include repos that are immutable
3. Allow a user to define a regex to include tags that are immutable

2 & 3 are not mutually exclusive

by 2 & 3 not mutually exclusive,
I imagine something like immutability configured on for a repo, but a whitelist on tags that allows for certain exceptionalities like 'latest' can be overwritten repeatedly w/ no consequences

[cd1989]

Is this referring to nothing pushed to any repos in a project can be overwritten. But deletion are still allowed I assume

Yes

[michmike]

@xaleeks i meant above that you can use any combination of 1, 2, or 3.

let me rephrase it because you made an excellent point

Expose immutability using multiple policy options in Harbor under project settings. A user can use any combination of the below to define policy.

1. Make an entire project immutable
2. Allow a user to define a regex to include repos that are immutable
3. Allow a user to define a regex to include tags that are immutable
4. Allow a user to define a regex to exclude repos that are not immutable
5. Allow a user to define a regex to exclude tags that are not immutable

[xaleeks]

OK so it's 'whitelisting' at various levels. This is going to get groomed for 1.10. I will work on a gdoc PRD and share w/ everyone. Please watch this ticket if you're not already.

[xaleeks]

feel free add comments on requirement doc:
https://docs.google.com/document/d/1cPZGf8X0Z7YENp0rq8buq4_A0b2kZimzol6s26kP_lk/edit

[ernestomedina17]

I'm also interested in this new feature, +1 vote

[stuclem]

Created https://github.com/goharbor/harbor/issues/9572 to track the doc update, so removing doc-impact from this one.

[xaleeks]

This is done in our release of 1.10 today!! @tschwaller