feat(kms): Add KMS under beta

[JanStern]

Description

relates to #934

KMS has been added to the CLI. Now the following commands exist:

• key (create, delete, import, list, restore, rotate)
• key ring (create, delete, list)
• version (destroy, disable, enable, list, restore)
• wrapping key (create, destroy, list)

Checklist

• Issue was linked above
• Code format was applied: make fmt
• Examples were added / adjusted (see e.g. here)
• Docs are up-to-date: make generate-docs (will be checked by CI)
• Unit tests got implemented or updated
• Unit tests are passing: make test (will be checked by CI)
• No linter issues: make lint (will be checked by CI)

---

Important Decisions

The CLI implementation of KMS reflects the state of the API, which includes some seemingly unfinished decisions.

1. The Region doesn't matter even though it exists: Every API Endpoint has the region as a required attribute. However, the value is currently meaningless. All requests have the same result no matter what the region is. Still I haven't removed/mocked the structure in the code since I assume that in the future KMS will be region specific.
2. Backend is a fixed but required value: When creating a wrapped key or a key, backend is a required body parameter that is currently only "software". Here following the same argument as before I have made it a flag in anticipation of future updates.
3. I recommend extra detail to Importing a Key: Following this example I experimented with the key importing and tried to import an invalid key. I did encode random text in base64 and it was accepted. It created a new key version but with the status "Errors existing", which feels wrong. Nonetheless, I don't think that the formatting checks in the CLI should be stricter. (I just wanted to draw attention to that)

---

Hope this actually helps and huge thanks to whomever tries to tackle this monster merge.

[JanStern]

@rubenhoenle are there any updates on the PR? I would love to use it in my pipeline.

[rubenhoenle]

Suggested change

	testRegion = "eu01"
	const testRegion = "eu01"

[rubenhoenle]

The Region doesn't matter even though it exists: Every API Endpoint has the region as a required attribute. However, the value is currently meaningless. All requests have the same result no matter what the region is. Still I haven't removed/mocked the structure in the code since I assume that in the future KMS will be region specific.

Well, the region is required for every API endpoint, it will just be "eu01" for now all the time. But please use the regular multi-region implementation like we do for all the other commands. So we're ready for the future :)

Backend is a fixed but required value: When creating a wrapped key or a key, backend is a required body parameter that is currently only "software". Here following the same argument as before I have made it a flag in anticipation of future updates.

Backend was deprecated in the v1beta version of the KMS service API already and got removed with the switch to the v1 version. So you'll have to remove it anyways, sorry 😄

[JanStern]

@rubenhoenle all so far requested changes should be addressed. Are you making progress on your tests?

[rubenhoenle]

@JanStern please check the failing CI pipeline. I also can't build the STACKIT CLI with the current state of the PR on my machine.

Edit: Most likely related to #1016

[JanStern]

@JanStern please check the failing CI pipeline. I also can't build the STACKIT CLI with the current state of the PR on my machine.

Edit: Most likely related to #1016

I just blindly merged main into this branch and didn't watch the Pipeline outcomes. Sorry and thank you for pointing that out @rubenhoenle.

I just resolved and addressed the issue.

[rubenhoenle]

@JanStern wanted to test now, but most of the examples provided in the help output just don't work. Giving up for today.

[JanStern]

When changing the flag key-ring to key-ring-id I forgot to change the examples too. That is 100% on me and unacceptable.

I also fixed the async feedback to reflect the difference between Created and Triggered creation of. I apologize for missing that.

---

When it comes to the output not working, I was scared for a minute. From your examples I see that you didn't provide the actual IDs of the Key-Ring but instead tried it with the name "my-key-ring-id". This is just a placeholder in the example. I understand that using --key and --key-ring as flags but expecting the UUIDs of these element might be confusing (even if I personally would even prefer it). That is why I changed it to --key-id and --key-ring-id.
When you go through testing all these examples you have to really keep the logic and dependencies in mind.

• Key requires Key Ring
• Version requires Key Ring + Key
• Wrapping Key requires Key Ring + Key

A small warning, you can only schedule the deletion for a key to happen after 30 days. Even if you have scheduled the deletion of a Key you will be charged for the entire 30 day period. Furthermore, you will be charged for every version that the key has. When testing for this PR I created (in my opinion) only a few keys with a few versions each and was billed quite a lot (~25€ in total) for it. With other words, testing this feature can be a bit expensive.

With that said, it would be awesome to be able to overwrite the strict 30 days deletion schedulation period. This is my formal request for that.

[rubenhoenle]

When it comes to the output not working, I was scared for a minute. From your examples I see that you didn't provide the actual IDs of the Key-Ring but instead tried it with the name "my-key-ring-id". This is just a placeholder in the example. I understand that using --key and --key-ring as flags but expecting the UUIDs of these element might be confusing (even if I personally would even prefer it). That is why I changed it to --key-id and --key-ring-id.

Yes, I'm aware of that and I also used the UUIDs in my examples. Just used the examples to show you the error I got. I was hoping you get my point then better without running into some wrong direction. I really hope I didn't confuse you with that 😅

[rubenhoenle]

With that said, it would be awesome to be able to overwrite the strict 30 days deletion schedulation period. This is my formal request for that.

I'm sorry, we as the STACKIT Developer Tools team can't change the behaviour of STACKIT services like e.g. KMS in this case. But I will forward this to the KMS team for you 😊

[rubenhoenle]

Looks good now to me, also the testing part.

I have only one last nitpick: The command for the key ring is called stackit beta kms keyring ... but the flag is spelled key-ring-id. You see the problem? Once it's keyring, once key-ring-id. Maybe we can rename all the flags from key-ring-id to keyring-id in terms of user friendliness?

Sorry for noticing this now, it just came into my mind during the testing now... I think with some search&replace this should be doable without too many pain. What do you think? 😅

Nevertheless, have a nice weekend!

[JanStern]

I agree! I wanted to bring up the same.
I even want to take it a bit further. I think keyring is one new object and deserves to be written as one word.
It feels more fitting to me, since a keyring is not part of a key (as maybe key-ring would suggest). It is part of KMS and a key is part of a keyring. I think the KMS team would understandably disagree, but I just wanted to mention it.

Furthermore, let me point out that the API Doc is also inconsistent. Most likely it is a spelling error, but maybe they deep down desire to move to keyring 🙃

Finally, I also like to go from --key-id and --key-ring-id to only --key and --keyring (or key-ring). I would argue that it become obvious after the first try that the CLI always expects IDs over names and then it looks cleaner in the long run.

So, what do you think? keyring or key-ring? --key-id or --key?

Your wish is my command! I just wanted to give you my arguments.

Cheers, wish you a good weekend too.