-
-
Notifications
You must be signed in to change notification settings - Fork 119
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: ebourg/jsign
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 7.1
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: ebourg/jsign
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: master
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 3 commits
- 16 files changed
- 2 contributors
Commits on Feb 14, 2025
-
Configuration menu - View commit details
-
Copy full SHA for 6db9112 - Browse repository at this point
Copy the full SHA 6db9112View commit details
Commits on Mar 22, 2025
-
Also query ECS container creds endpoint for KMS when no storepass is set
Issue #147 and its linked PR made it much more ergonomic to use `jsign` within an AWS EC2 instance, but as highlighted in the latter comments on that issue, it's not helpful when running ´jsign´ in the context of AWS Elastic Container Service (ECS) based products, such as AWS Fargate, AWS Codebuild, and AWS Greengrass. The precise technical reason for this is that ECS environments don't have that EC2 IMDSv2 endpoint exposed to them, so they can't use it. [As the official AWS SDK documentation states](https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/credentials-chain.html), the official SDK handles this situation by fetching credentials from a specific ECS container credentials endpoint, which doesn't share any host or path with IMDSv2, on the `ContainerCredentialsProvider` class. Roughly, the official container credentials provider works as follows: - If the `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` environment variable is set, it concatenates it with a well-known base URI, `http://169.254.170.2`, configurable through the [`AWS_CONTAINER_SERVICE_ENDPOINT`](https://github.com/aws/aws-sdk-java-v2/blob/186b433dd32366b095c8bc415342accb8b734cf7/core/sdk-core/src/main/java/software/amazon/awssdk/core/SdkSystemSetting.java#L112) parameter. (In production deployments, such URI can be considered a constant; changing it is mainly useful for testing purposes.) Then, it sends a HTTP GET request to the resulting endpoint, which is expected to return a JSON object in its body with the AWS credentials for the container. Optionally, an `Authorization` header in the request may be set to the value of either the `AWS_CONTAINER_AUTHORIZATION_TOKEN` or `AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE` environment variables, if any of those are set. - Else, if the `AWS_CONTAINER_CREDENTIALS_FULL_URI` environment variable is set, the same request as above is sent to the endpoint determined by this variable, without any modification. The contents and handling of the response to this request are the same as above. Experimentally, I've found AWS Fargate to only set `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`, without any authorization token. But the AWS documentation suggests that AWS EKS may make use of the full URI and token environment variables, so it's fair to say that supporting them is also useful in practice. To improve on the situation, these changes implement a lightweight but feature-complete ECS container credentials client in ´jsign´. This credentials client attempts to fetch credentials before its counterpart for IMDSv2, which guarantees that both EC2 and ECS environments are handled appropriately without any manual configuration, following the same logic as the AWS SDK. If neither credentials provider worked, the user is instructed to manually pass AWS credentials as before, and the resulting exception stack trace contains details on why both providers failed. I've tested this custom client logic to work successfully on a real AWS Fargate deployment. The documentation was also updated to reflect this new provider, and unit tests for it added.
Configuration menu - View commit details
-
Copy full SHA for c0cb9fa - Browse repository at this point
Copy the full SHA c0cb9faView commit details -
Configuration menu - View commit details
-
Copy full SHA for 535387c - Browse repository at this point
Copy the full SHA 535387cView commit details
There are no files selected for viewing