Support for handling resource life-cycle modifiers

[barney-s]

Feature Description

Problem Statement:

We want to support different life-cycle modifiers such as:

1. Create : allowed or not , force re-create if it exists
2. Delete : allowed or not
3. Update : allowed or not

Some example use cases:

1. Annote a service account. May be create. But dont delete it.
2. Create a DB object, but dont delete it.
3. Create a Job but dont delete it.

Proposed Solution:

resources:
  - id: something
     template: ...
     lifecycle:
          create: always* | once | never
          delete: always* | abandon
          update: always* | never

Alternatives Considered:

For KCC (https://cloud.google.com/config-connector/docs/overview), the individual objects support its own lifecycle annotation to deal with the underlying GCP objects. We can use it for these resources.

Use annotations on the resource being created.

resources:
   id: something
   template:
      ...
      metadata:
         annotation:
            kro.lifecycle.delete: abandon

Advantage is this allows user to modify object lifecycle without modifying RGD for break-glass.

Additional Context:

#537

Resource annotateDefaultServiceAccount is the default SA created by Kubernetes for a namespace. We want to annotate it for Workload identity but not delete it.

• Please vote on this issue by adding a 👍 reaction to the original issue
• If you are interested in working on this feature, please leave a comment

[a-hilaly]

related #183

[ellistarn]

I was discussing something similar with @a-hilaly in DMs:

---

[] <-- Watcher (just read)
[Create] <-- (create and read, but don't update? Footgun?)
[Create, Update] <-- Donor (create and update it, but never delete? This is Retain)
[Create, Update, Delete] <-- Owner (this is normal management)
[Update] <-- (dont create it, but update it, and never delete. Footgun?)
[Update, Delete] <-- Adopter (don't create it, but you own this now)
[Delete] <--(read it, never change it, but kill it? Footgun?)

4 real use cases that aren't footguns: Owner, Watcher, Donor, Adopter.

We were debating whether or not to decompose each of the actions or to roll the combinatorics into some first class concepts.

---

There are a few things in your post that aren't capture here, like create once, though I'm not sure I understand the use case there.

[barney-s]

ooh i like how the common patterns have names :)