-
Notifications
You must be signed in to change notification settings - Fork 206
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
Load Balanced Signing #468
Comments
Hacking on this a little bit. The What I need is a way to set the access key and session key on an a per request basis. |
Is this still relevant @rcollette? This functionality is not supported here afaik, but PRs are welcome. |
@jakubzitny This is still an issue. Thinking about it more, the ideal situation for this would be that the API returning the signed url, could return an object rather than a string. The object would contain both the signed url and the session token that was used to sign the url, and when a session value is present, it would set the appropriate request headers.
The headers we currently set are shown here: public async uploadToS3(
targetFile: File,
guid: string,
progressTracker: (p: number, stats: TransferStats) => void
): Promise<any> {
// Get the signing configuration each time because the session token may get renewed.
const configuration = await this._getSigningConfiguration();
return this._evaporateInstance.add({
name: `software/${guid}/${targetFile.name}`,
file: targetFile,
complete: (_result) => {},
progress: progressTracker,
error: (error) => {
this._logger.error(error);
},
// IAM Roles use a temporary credential that has a session token that must be passed
xAmzHeadersCommon: configuration.sessionToken
? {
'x-amz-security-token': configuration.sessionToken,
}
: undefined,
xAmzHeadersAtInitiate: configuration.sessionToken
? {
'x-amz-security-token': configuration.sessionToken,
}
: undefined,
});
} |
If the |
Neither of those methods provides the ability to set the session key header. That value is set in the evaporate instance. I need a way to set x-amz-security-token on a per request basis since the each instance in the load balanced pool (Fargate, Beanstalk, etc) that is performing signing has a different sessionToken. I might be willing to contribute but "V3" has been hanging out there for so long with no momentum, I'm hesitant to allocate time that will hit a roadblock anyway. |
I see, sorry I didn't realize this. Okay, let's sync with others to see if we can push v3. (#450) |
In a load balanced Fargate service, each task has it's own set of temporary credentials but share the same IAM role.
EvaporateJS only allows the configuration of one set of access key and session key. If the instance signing a URL has a different set of keys from the one supplied in the client setup, then I get 403 errors.
The only way I can think of making this work without something like sticky sessions in the LB (yuck), is to store the temporary credentials in a some shared store (ex. Redis) such that all load balanced instances are signing with the same credentials. But then there is session expiry management throwing a wrench in there.
Is there a typical pattern for handling signing or configuring the client when using an IAM Role in a load balanced scenario?
The text was updated successfully, but these errors were encountered: