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]

After you put so much effort in another round of reviews, @rubenhoenle, I went through everything again really carefully and:

1. Changed the output format, so that every JSON/YAML outputs a clean state of the object.
2. Moved Flags to Args and Arg to Flags so that it fits the format.
3. Fixed all the other small issues.

I also carefully tested all possible commands and fixed small issues that appeared. Namely, 1) not trying to output a non existing wrapping key because it was just deleted, and 2) properly adding the 'protection' field required for key creation in the /v1.

I think now I have for the first time really understood your intentions and I can only imagine your frustration with me. It seems quite obvious what you wanted and I just didn't do it multiple times.
I apologize and I thank you for being so patient with me.

This is an absolute monster PR and hope these new commits moved it forward a lot.
Curious for your thoughts 😄

[rubenhoenle]

@JanStern looks pretty great overall, I started using the kms with CLI locally and found some inconistencies in the examples. Will do some manual testing now to find possible further issues. But we're getting close to the merge point 😊

[rubenhoenle]

I think now I have for the first time really understood your intentions and I can only imagine your frustration with me. It seems quite obvious what you wanted and I just didn't do it multiple times. I apologize and I thank you for being so patient with me.

This is an absolute monster PR and hope these new commits moved it forward a lot. Curious for your thoughts

Oh, nothing to feel sorry about here. We're thankful for all contributions, also for yours!

It can take some time to get into a new codebase and I'm also not thaaat long in the team now, so I hope I can also improve my review process a little bit. This PR was a challenge for both of us ^^

The only thing I would ask you for upcoming contributions (and also a lesson I learned from this PR): Try to split PRs into smaller ones. So e.g. for the kms here, consider doing it like that:

• Create a first PR which implements the base stackit beta kms command and e.g. the stackit beta kms keyring command with all it's subcommands like create, delete, ...
• Then create a second PR which implements the stackit beta kms key command with all it's subcommands
• ... And so on I hope you get the idea 😅

Then you have smaller PRs, which can be reviewed & merged faster - and the most important: You get to know the codebase within the first PR and both you and us will have a much better time during the upcoming PRs.

As said, also a lesson for me to reject such a monster PR in the first place and ask the author to split it apart before even trying to review such a monster. Will also try to include this in our contribution guide 😊