Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support the Azure VM-assigned managed identity for automatic KMS credentials #1035

Merged
merged 5 commits into from
Nov 4, 2022

Conversation

jyemin
Copy link
Contributor

@jyemin jyemin commented Nov 3, 2022

JAVA-4706

  • Add support for obtaining Azure credentials for KMS using local endpoint
  • Refactored GCP-specific integration test to handle both GCP and Azure

After discussing with Kevin, determined that given the coverage provided by the integration tests, there is not enough additional value in the unit tests (which require starting a mock server) to get them running in CI. So although they are implemented in the first commit, they are removed in the second one.

This unit test is not pulling enough weight given the success/failure integration tests we already have.  Removing and simplifying the production code now that we no longer need to mock the endpoint.
@jyemin jyemin self-assigned this Nov 3, 2022
export AZUREKMS_RESOURCEGROUP=${testazurekms_resourcegroup}
export AZUREKMS_VMNAME=${AZUREKMS_VMNAME}
export AZUREKMS_PRIVATEKEYPATH=/tmp/testazurekms_privatekey
AZUREKMS_CMD="MONGODB_URI='mongodb://localhost:27017' PROVIDER="azure" ./.evergreen/run-fle-on-demand-credential-test.sh" $DRIVERS_TOOLS/.evergreen/csfle/azurekms/run-command.sh

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder why did you miss KEY_NAME='${testazurekms_keyname}' KEY_VAULT_ENDPOINT='${testazurekms_keyvaultendpoint}'?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like those values are hardcoded in the integration test. Is that not ok?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

better to use env variables instead hardcoded values. That values are going to be changed in this ticket https://jira.mongodb.org/browse/BUILD-16154. Then, applying it in the driver will be easier with env variables instead of changing it in the code. NOTE: we will need to change the code in c# driver, my fault :(

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link

@DmitryLukyanov DmitryLukyanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see this part in this PR: mongodb/specifications@d6b8cce#diff-de01d398114f63480af23798e09ffca599aa758efd04f15a9beec89b4566041bR344. Has it been implemented somewhere else?

@jyemin
Copy link
Contributor Author

jyemin commented Nov 4, 2022

Agreed to defer credential caching to subsequent PR. Is there anything else missing besides that?

@jyemin
Copy link
Contributor Author

jyemin commented Nov 4, 2022

@DmitryLukyanov ready for another look

Copy link

@DmitryLukyanov DmitryLukyanov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM (assuming tests passed)

@jyemin jyemin merged commit 1ef1b5e into mongodb:master Nov 4, 2022
@jyemin jyemin deleted the j4706 branch November 4, 2022 21:00
ispringer pushed a commit to evergage/mongo-java-driver that referenced this pull request May 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants