Conversation
Store implementations may support tagging secrets immediately after they are created, as a convenience and a basis for future enforcement of tagging. As usual, only the SSM store implementation supports the new feature. The README is updated with documentation about both this new feature and the recently added tag commands.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #516 +/- ##
==========================================
+ Coverage 35.97% 35.99% +0.01%
==========================================
Files 29 29
Lines 2524 2545 +21
==========================================
+ Hits 908 916 +8
- Misses 1538 1550 +12
- Partials 78 79 +1 ☔ View full report in Codecov by Sentry. |
Sabrina0614
left a comment
Sabrina0614
left a comment
There was a problem hiding this comment.
Looks great! Just some questions. Thank you for adding it and also update the README
|
|
||
| if len(tags) > 0 && version != 1 { | ||
| return errors.New("tags on write only supported for new secrets") | ||
| } |
There was a problem hiding this comment.
❓ Curious if there is a particular reason why tagging is only support for new secrets? Sorry if I am missing it somewhere
There was a problem hiding this comment.
You didn't miss anything! (I thought for a second that I had documented why, but it's just in my notes.) I was thinking of what chamber should do when the secret already exists and it already has tags.
- If you include
--tags, what should happen to the other tags that you don't list? Should they be deleted or left alone? Admittedly, we could add the--delete-other-tagsoption fromchamber tag writeto let you pick. - If you do not include
--tags, what should happen to the existing tags? Should they be all dropped out or left alone? We could maybe add another option,--delete-existing-tagsor something, to let you pick.
It's because of this complexity that, at least for this pass, I opted to restrict tags to just new secrets.
There was a problem hiding this comment.
thank you for the context! I did not know that it would override the existing tag prior.
| } | ||
|
|
||
| if len(tags) > 0 { | ||
| if err := s.WriteTags(ctx, id, tags, false); err != nil { |
There was a problem hiding this comment.
❓ (More of the WriteTags method) - It looks like the WriteTags also take in deleteOtherTags, curious what would happen for the following case:
- If there already exist a tag for a secret, let's say it has tag
app = backstageand another tagrequiredChamber = true - I then now call write tag for this secret with the
app = backstageand withdeleteOtherTagsis set to true, it will remove therequired = chamber, but would it error out if we are trying to add the tag that already exist?
There was a problem hiding this comment.
If I understand your scenario correctly, it would be fine, because you can use chamber tag write to replace the value of an existing tag, and it's fine if the new value is the same as the old value.
In the implementation of WriteTags, first all of the tags which are not being written are deleted; because the app tag is being written, it isn't deleted. Then, the app tag is updated using the SSM add-tags-to-resource API, which either adds or overwrites tags.
Let me know if I misunderstood your scenario!
There was a problem hiding this comment.
makes sense! thank you for walking me through it!
2 participants
Store implementations may support tagging secrets immediately after they
are created, as a convenience and a basis for future enforcement of
tagging. As usual, only the SSM store implementation supports the new
feature.
The README is updated with documentation about both this new feature and
the recently added tag commands.