CLOUDP-167207: Validate GCP Service Account Key

[josvazg]

All Submissions:

• Have you signed our CLA?
• Put closes #XXXX in your comment to auto-close the issue that your PR fixes (if there is one).
• Update docs/release-notes/release-notes.md if your changes should be included in the release notes for the next release.

[github-actions]

https://app.codecov.io/github/mongodb/mongodb-atlas-kubernetes/commit/80ac13c7284a7f472090c6d7f3fb50c1b6f47959

[helderjs]

Overall looks good, just have a few comments and 2 extra thoughts:

1. Does it make sense to have an e2e test to see how an escaped string from an applied yaml would go through the validation?

2. Talking to @igor-karpukhin, we were wondering if makes sense to validate the entire service account object, once Atlas API will check it is really valid and can be used to connect to GCPP.

[josvazg]

Overall looks good, just have a few comments and 2 extra thoughts:

1. Does it make sense to have an e2e test to see how an escaped string from an applied yaml would go through the validation?
2. Talking to @igor-karpukhin, we were wondering if makes sense to validate the entire service account object, once Atlas API will check it is really valid and can be used to connect to GCPP.

I am doing some manual testing at the moment before I decide how to proceed there. I am hesitant to add up more to our slow and flaky e2e tests, unless for a very good reason that has no better alternative.

I think the validation against the API was not the initial idea. We could do that, even before we deploy anything in the cloud. And that could be a fast e2e test as it is a single check and does not require a cloud resource deployment to take place beforehand.

[josvazg]

Overall looks good, just have a few comments and 2 extra thoughts:

1. Does it make sense to have an e2e test to see how an escaped string from an applied yaml would go through the validation?
2. Talking to @igor-karpukhin, we were wondering if makes sense to validate the entire service account object, once Atlas API will check it is really valid and can be used to connect to GCPP.

In the end I added the same tests as e2e test as well, but the happy path case is using the format that we can recommend to end users when setting up the keys, just take the service account JSON file from Google and put it, as is, in the CRD YAML as a multiline attribute:

apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
spec:
  name: Test Atlas Operator Project
  encryptionAtRest:
    googleCloudKms:
      enabled: true
      keyVersionResourceID: projects/...
      serviceAccountKey: |
        {
          "type": "service_account",
          "project_id": "...",
          ...
        }

The only caveat is to respect the indentation, as seen in the example, so that the YAML format knows this file is a document for serviceAccountKey

[igor-karpukhin]

Looks good in general 👍 , but let's not separate this test from other "encryption-at-rest" tests

[helderjs]

Good work!

[igor-karpukhin]

Looks good 👍