Repository navigation
CAMEL-25675: camel-hashicorp-vault - AWS IAM, Azure managed identity and GCP Compute Engine logins - #29708
CAMEL-25675: camel-hashicorp-vault - AWS IAM, Azure managed identity and GCP Compute Engine logins#29708oscerd wants to merge 2 commits into
Conversation
…and GCP Compute Engine logins The endpoint, the hashicorp: properties function and the secret refresh task can log in with the identity the cloud gives the application: aws-iam (the AWS SDK default credentials chain, with awsRegion, awsStsEndpoint and awsIamServerId; the AWS SDK auth module is an optional dependency, used only by this login), azure-msi (the managed identity token for azureResource, by default https://management.azure.com/, and azureClientId for a user-assigned identity) and gcp-gce (the service account of the Compute Engine instance). The metadata services are called without a proxy. The review of the TLS change: the role, authMountPath and keyStore descriptions cover the cert login and PKCS#1, the docs say the stores are read when the client is created, a trust store that reads as empty fails with a hint about its password, and a test reads an EC key. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
gnodet-bot
left a comment
There was a problem hiding this comment.
LGTM. No issues found.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
davsclaus
left a comment
There was a problem hiding this comment.
TL;DR: a clean finish to CAMEL-25675 and the library wiring checks out. Two aws-iam points (the IRSA dependency in the docs, and the default signing region) are worth fixing before merge, plus a couple of small suggestions.
I checked the wiring against Spring Vault 4.1.1 and AWS SDK 2.57.11: the VaultClient/RestClient constructors exist; the Azure token URI is passed as a URI, so the encoded resource/client_id values are not encoded twice; the role assertions of the Azure and GCP builders match our validation; and the credentials provider is closed on every path, including the failure paths of create(). The five new options are carried consistently through the endpoint, camel-api (with @since 4.24), camel-main, the env vars and the generated files, and none of them needs secret=true. Running the aws-iam test as a real signed login against the fake Vault is a nice touch.
1. IRSA needs the sts module (important). The Cloud logins section (hashicorp-vault-component.adoc around line 146) and the Javadoc of HashicorpVaultAwsIam list a web identity token (IRSA on EKS) in the default chain, with only software.amazon.awssdk:auth added. In the SDK, the web identity provider loads StsWebIdentityCredentialsProviderFactory from the sts module by reflection ("To use web identity tokens, the 'sts' service module must be on the class path"). Without software.amazon.awssdk:sts, the default chain skips web identity and continues to the container or instance-profile providers, so on EKS the app can log in to Vault as the node's role rather than the pod's. Could we document sts for web identity (and sso/ssooidc for SSO profiles)? Optionally, a hint in the validation when AWS_WEB_IDENTITY_TOKEN_FILE is set and the sts class is missing.
2. Default signing region vs the global endpoint (important / question). When awsRegion is not set, HashicorpVaultAwsIam.options keeps Spring Vault's default region provider chain, while the endpoint stays the global https://sts.amazonaws.com/. As the docs say, the global endpoint wants us-east-1 signatures. But AWS_REGION is set in exactly the places this login targets (the EKS IRSA webhook, ECS, Lambda), so the default config would sign for e.g. eu-west-1 and STS would refuse the login; where no region can be resolved, the chain throws at login. Vault's own vault login -method=aws defaults the region to us-east-1. What about signing for us-east-1 when neither awsRegion nor awsStsEndpoint is set? The default test (HashicorpVaultCloudLoginTest.java:113) sets aws.region=us-east-1, so it passes either way; a case with another SDK region would cover this. Changing the default after the release would need an upgrade-guide entry, so now is a good time.
3. aws-iam without a role (suggestion). HashicorpVaultClient.java:200 requires role for aws-iam, but Spring Vault leaves it out of the login body when empty, and Vault then uses the IAM principal's friendly name as the role. It could be optional, as for jwt. Azure and GCP do need it.
4. Docs example (suggestion). A short camel.vault.hashicorp.* example in the Cloud logins section (e.g. authentication = aws-iam, role, awsRegion) would match the TLS and kubernetes sections.
Nits: the kubernetes case at HashicorpVaultClient.java:178 could use the new validateRole helper; the env-var sentence around hashicorp-vault-component.adoc:461 is not wrapped like the rest of the page.
Claude Code on behalf of davsclaus. This review was generated by an AI agent and may contain inaccuracies; please verify all suggestions before applying.
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 587 of 723 tested, 0 compile-only — current: 587 all testedMaveniverse Scalpel detected 587 affected modules (current approach: 587). Skip-tests mode would test 587 modules (6 direct + 29 downstream), skip tests for 0 (generated code, meta-modules) Modules Scalpel would test (587)
Build reactor — dependencies compiled but only changed modules were tested (6 modules, 2m 14s total)Total reactor time: 2m 14s
Top 20 slowest modules:
|
…ws-iam login Without awsRegion and awsStsEndpoint, the aws-iam login signs its request for us-east-1, which the global STS endpoint needs, as vault login -method=aws does. The role is optional for aws-iam: Vault then takes the role named as the IAM principal. A web identity token (such as IRSA on EKS) needs the sts module of the AWS SDK, without which the SDK falls through to other credentials: the docs say so, and the validation fails when AWS_WEB_IDENTITY_TOKEN_FILE is set and the sts module is missing. The Cloud logins section has an aws-iam example; the kubernetes validation uses validateRole. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
|
Thanks, all applied in f177c76:
Nits: the kubernetes case uses Claude Code on behalf of oscerd |
gnodet-bot
left a comment
There was a problem hiding this comment.
Following up on my earlier review — all previous findings have been addressed.
The second commit (f177c76) correctly resolves the 4 items raised:
- IRSA /
stsmodule —validate()now fails fast whenAWS_WEB_IDENTITY_TOKEN_FILEis set andStsWebIdentityCredentialsProviderFactoryis absent; docs updated accordingly. - Default signing region — global STS endpoint now defaults to
us-east-1signature (matchingvault login -method=aws); regional endpoint withoutawsRegionuses the SDK chain. Three dedicated tests cover all three branches. roleoptional for aws-iam —validateRoleremoved from theAWS_IAMcase; role conditionally set inoptions(). Test confirms role key is absent from the login body when not configured.- Docs example —
camel.vault.hashicorp.*example added in the Cloud logins section.
The nits are also addressed: kubernetes case uses the validateRole helper, env-var paragraph is rewrapped.
Test coverage for all new behaviour is thorough (8 new test methods for region signing, optional role, IRSA validation, Azure and GCP option construction). No new issues found.
This review was generated by an AI agent, Hermès on behalf of @gnodet.
Summary
Third and last PR for CAMEL-25675, after #29235 (AppRole, Kubernetes, JWT, token renewal) and #29619 (TLS and the cert login). It adds the cloud logins to the
hashicorp-vaultendpoint, thehashicorp:properties function and the secret refresh task, and the follow-ups of the review of #29619.Cloud logins (
authentication=), each withroleandauthMountPath:aws-iam: Spring Vault'sAwsIamAuthentication, with the credentials of the AWS SDK default chain (environment, system properties, web identity such as IRSA on EKS, profile, ECS container, EC2 instance profile). The AWS SDK is an optional dependency (software.amazon.awssdk:auth,${aws-java-sdk2-version}): the login is in a class of its own, loaded only foraws-iam, and the validation says which dependency to add when it is missing. New options:awsRegion(the signing region),awsStsEndpoint(default the globalhttps://sts.amazonaws.com/, which takes requests signed forus-east-1) andawsIamServerId(theX-Vault-AWS-IAM-Server-IDheader). WithoutawsRegionandawsStsEndpoint, the request is signed forus-east-1, asvault login -method=awsdoes; with a regional endpoint and noawsRegion, for the region of the SDK default chain.roleis optional: without it, Vault takes the role named as the IAM principal. A web identity token (IRSA on EKS) also needssoftware.amazon.awssdk:sts(an SSO profilessoandssooidc): without it the SDK falls through to other credentials, so the validation fails whenAWS_WEB_IDENTITY_TOKEN_FILEis set and thestsmodule is missing. The credentials provider is closed with the client.azure-msi: Spring Vault'sAzureMsiAuthentication, with the token of the managed identity forazureResource, which must be the resource of Vault's Azure login. The default ishttps://management.azure.com/, as in Vault's Azure login documentation, rather than Spring Vault'shttps://vault.hashicorp.com.azureClientIdchooses a user-assigned identity. A pod of AKS with workload identity gets its identity as a token in a file rather than from the instance metadata service: the docs point it to thejwtlogin withjwtFile.gcp-gce: Spring Vault'sGcpComputeAuthentication, with the identity token of the default service account of the instance.gcp-iamis left out: it needsgoogle-cloud-iamcredentials(gRPC, not managed in the parent POM) and only works with a service account key file.Follow-ups of the review of #29619
role,authMountPathandkeyStoreoption descriptions now covercertand PKCS#1, and the cloud logins.trustStorePassword: a keytool-made PKCS12 trust store read without its password does come back empty (tested).HashicorpVaultTls.Tests
HashicorpVaultCloudLoginTest: theaws-iamlogin against the fake Vault, with credentials and region from the AWS SDK system properties. It checks the request URL, the body, the server ID header and the region of the signature:us-east-1with the global endpoint even when the SDK region iseu-west-1, the SDK region with a regional endpoint, andawsRegionwhen set. Also the login withoutrole, and the validation error for a web identity token without thestsmodule. Theazure-msiandgcp-gceoptions (token URI with resource and client ID, role, mount path, service account), and creating and closing their clients without reaching the cloud. The role is required by the three logins.HashicorpVaultTlsTest: the EC key and the empty trust store.HashicorpVaultClientSettingsTest: the cloud settings from the environment variables and the configuration.mirror.gcr.io/hashicorp/vault:2.2.1(no new integration test: the cloud logins need a cloud identity). Full reactor build (mvn clean install -DskipTests -DskipITs) with the regenerated files committed.CAMEL-25675 was resolved when #29619 was merged; it is reopened for this last PR.
Claude Code on behalf of oscerd
🤖 Generated with Claude Code