Add Conditional Immutability Policy Proposal

[bupd]

Summary

• Adds proposal for conditional immutability rules that works/complements with retention policies
• Introduces time-based conditions for immutability policy: nDaysSinceLastPush and nDaysSinceLastPull
• Maintains backward compatibility with existing "always immutable" behavior

Problem

Immutability currently blocks all deletes at the API level, forcing users to manually toggle immutability off/on to allow retention policy cleanup.

Solution

Allow immutability rules to specify conditions under which artifacts remain immutable, reusing existing retention policy evaluators.

• Issue: Retention Policies for Immutability Tags harbor#20989
• Implementation PR: Add Conditional Immutability Rules Compatible with Retention Policy harbor#22047

[reasonerjt]

@bupd

If the intention is to skip retention policy why not just update the condition in the retention policy?

[bupd]

If the intention is to skip retention policy why not just update the condition in the retention policy?

There might be a misunderstanding,

The intention is not to skip retention policy - it's the opposite. The goal is to enable retention policy to work on artifacts that were previously immutable.

Proposal is to add Conditional immutability policy that makes artifacts enter and exit immutability based on conditions (e.g., "immutable if pulled within last 15 days"). When an artifact exits the immutability window, it becomes mutable again and retention can clean it up

[Vad1mo]

The goal here is that for most users immutability is not forever.
Most teams want to have immutable images for, let's say, 365 days, or in legal cases, 5 to 10 years.

[reasonerjt]

Most teams want to have immutable images for, let's say, 365 days, or in legal cases, 5 to 10 years.

But I believe this can be translated to conditions in retention policy, for example, make the retention policy delete images that were pushed more than 356 days ago. The idea is that IMO we should limit the complexity in retention policy, so when the images are not deleted as expected it's easier to debug and test.

[Vad1mo]

But I believe this can be translated to conditions in retention policy, for example, make the retention policy delete images that were pushed more than 356 days ago. The idea is that IMO we should limit the complexity in retention policy, so when the images are not deleted as expected it's easier to debug and test.

No, retention policies don't affect immutable images. That's why this proposal.

If retention policies altered "immutable" images, it would contradict the point of "immutability".

Something that is immutable cannot be mutable at the same time. So the retention policy is working as expected here, ignoring immutable images.

The only solution to this paradox is to have conditional mutability rules.

When you create an immutability rule, you can say: I want this immutability to be forever (current state)," or have a "condition" that says the immutability should exist for x days for last pushed/last pulled images. Then the immutability does not apply anymore. The image won't be deleted. Once the immutability is gone, the image can be cleaned up by the retention policy.

[bvdriel]

I think what is missing in the discussion is the three use cases (at least those I see):

1. We want to protect artifacts from being deleted while in use
2. We also want to protect artifacts from being overwritten (by subsequent cicd or users or mailicious attack
3. We want to clean what can be cleaned because it is not used anymore

Immutability is the only now by enabling 1 and 2, disabling 3

It should be possible to enable all with a combination of retention and immutability rules.

But by currently not allowing for tailored ruling, once immutable, always immutable. And that prevents cleanup for old production images en artifacts, which is troublesome.

So either the solution should be (imho):

• make immutability rules more flexible, but it could probably lead to possible conflicting retention policies and duplicate administration of retention rules
  Or
• enable retention over mutability artifacts, maybe with special retention rule list (just like separate rules for untagged vs tagged, you could add retention rules for immutables)

[Vad1mo]

@bvdriel thank you for your input. The proposal addresses exactly your sketched-out use case 3 while preserving use existing case 1 and 2.

you can see in the screenshots of PR goharbor/harbor#22047

[reasonerjt]

@bvdriel Thanks for chiming in.

We want to protect artifacts from being deleted while in use.

So you mean protect the "in-use" artifacts from being deleted by humans, as well as the retention policy? So essentially, you wanna reduce the effort to update the immutability rules when the artifacts are no longer used. I think this makes sense, I was confused by the "abstract" section in the proposal.

@Vad1mo
What do you think about updating the retention policy, for example, adding a "force" flag, and the immutable artifacts will still be removed when the policy cleans up the artifacts? This could still solve the problem, right?

So the flow is:

1. Create the immutability rules to protect certain artifacts
2. Create the retention policy with the "force" flag, with a condition to retain the artifacts that are pulled within "xx" days.
3. When the retention policy is triggered, the artifacts that are not used will still be deleted.

I think this is easier for implementation and debugging. Adding more conditions to the immutability rule solves the problem, but I wish we could keep the complexity within the retention policy scope and avoid making immutability rules too complicated.

@bvdriel @bupd WDYT?

[bvdriel]

@bvdriel Thanks for chiming in.

We want to protect artifacts from being deleted while in use.

So you mean protect the "in-use" artifacts from being deleted by humans, as well as the retention policy? So essentially, you wanna reduce the effort to update the immutability rules when the artifacts are no longer used. I think this makes sense, I was confused by the "abstract" section in the proposal.

@Vad1mo What do you think about updating the retention policy, for example, adding a "force" flag, and the immutable artifacts will still be removed when the policy cleans up the artifacts? This could still solve the problem, right?

So the flow is:

1. Create the immutability rules to protect certain artifacts
2. Create the retention policy with the "force" flag, with a condition to retain the artifacts that are pulled within "xx" days.
3. When the retention policy is triggered, the artifacts that are not used will still be deleted.

I think this is easier for implementation and debugging. Adding more conditions to the immutability rule solves the problem, but I wish we could keep the complexity within the retention policy scope and avoid making immutability rules too complicated.

@bvdriel @bupd WDYT?

Hi,

Thinking about it, what is the use of NOT deleting immutables with retention schemes? retention policies are flexible enough to prevent deletion of active images, and to not delete images based on tags. (-Prd tags for instance).

To make something immutable is meant mainly I would say for unwanted overwrites or delete by humans or processes outside harbor.

I don’t think immutabillity should be able to evade retention policies that can easily be made to take into account use artifacts (last pulled) or special artifacts (last x pushed -prd tags)

so my suggestion then would be.

make retention policies ignore immutability.

What do you think? Makes everything easy and simple.

Immutability should restrict users (robots or humans) but not retention and cleanup.

Regards,
Bas

[reasonerjt]

@bvdriel

The original design of the immutability rule is to prevent anyone from deleting the image, including the retention policy.

So what you suggest:

make retention policies ignore immutability.

If we make the change it would be a break change, and some user's images will be deleted in an unexpected way. That's why I suggest adding a flag in retention policy, when it's set to true the retention policy will ignore the immutability rule. This ensures the backward compatibility.

[bvdriel]

@bvdriel

The original design of the immutability rule is to prevent anyone from deleting the image, including the retention policy.

So what you suggest:

make retention policies ignore immutability.

If we make the change it would be a break change, and some user's images will be deleted in an unexpected way. That's why I suggest adding a flag in retention policy, when it's set to true the retention policy will ignore the immutability rule. This ensures the backward compatibility.

👍🏻
That is a good solution imho
Maybe take some time to decide on naming.
‘Include immutable artifacts’
Or something? And make sure it is a Per Rule setting

I think this could be a good way for implementation.

[bupd]

@reasonerjt , @bvdriel as a user, I have serious concerns about letting retention policies override immutable policies Retention rules running on schedules could silently delete artifacts users explicitly wants to be protected. overall overriding immutability with any other policy is not a good idea.

If we let retention policy override immutability this would make harbor unpredictable.

I want the deletion intentional, not accidental.

thats conditional immutable policy, if the artifact doesnt fall under the conditions set, it will go out of immutability that is what the feature we are trying to add. so there is no confusion on which policy takes precedence over which.