leoberliant-adobe commented on PR #3232: URL: https://github.com/apache/jackrabbit-oak/pull/3232#issuecomment-6372047174
P2 — Nested source profiles can bypass fallback logging [ImdsV2CredentialsProvider.java, line 59](https://github.com/apache/jackrabbit-oak/blob/c5ecae6fd92782efec9c8da62edb6520ac37cd4f/oak-blob-cloud/src/main/java/org/apache/jackrabbit/oak/blob/cloud/s3/ImdsV2CredentialsProvider.java#L59) injects ec2_metadata_v1_disabled=true only into the selected profile. Consider this valid configuration: `[profile application] role_arn = arn:aws:iam::123456789012:role/Application source_profile = bootstrap [profile bootstrap] role_arn = arn:aws:iam::123456789012:role/Bootstrap credential_source = Ec2InstanceMetadata` With AWS_PROFILE=application, the override is added to application, but the SDK creates the metadata provider using bootstrap and its settings. The pinned AWS SDK’s credential-source implementation explicitly passes that source profile’s name. If token acquisition fails with a fallback-eligible response, that provider can successfully use IMDSv1 during the supposedly IMDSv2-only attempt. Oak therefore never enters its retry branch and never emits the new diagnostic. Recommended change: apply the first-attempt policy to profiles traversed through source_profile, with a regression test covering this configuration and a token-endpoint failure. The existing named-profile tests do not cover nested role profiles. What this means for AEM This PR does not introduce IMDSv2 support from scratch. The existing AWS SDK already attempts IMDSv2. It adds: An initial credential-chain attempt with IMDSv1 disabled through profile configuration. A compatibility retry using normal AWS policy. A one-time ERROR after that retry succeeds. Tests and operational documentation. IMDSv1 remains permitted by default. For an AEM deployment that must prohibit it, use EC2 HttpTokens=required; this PR alone is not enforcement. Explicit JVM/environment settings can also override its first-attempt profile policy. Static Oak access/secret keys remain on the unchanged path. Validation limits: this was a source-level review, including the pinned AWS SDK 2.37.5 implementation. I did not run the Maven tests. GitHub’s Maven build was queued when inspected; the passing-test counts in the PR description are author-reported. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
