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

Load Balanced Signing #468

Open
rcollette opened this issue May 26, 2021 · 6 comments
Open

Load Balanced Signing #468

rcollette opened this issue May 26, 2021 · 6 comments

Comments

@rcollette
Copy link

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?

@rcollette
Copy link
Author

Hacking on this a little bit. The this context of customAuthMethod provides access to aws_key. I could change it there and it shows up in the request that is made, although I wonder if it is "multiple request safe". However, the canonical request is already formed at this point and I haven't been able to alter it so I can set the session key header.

What I need is a way to set the access key and session key on an a per request basis.

@jakubzitny
Copy link
Collaborator

Is this still relevant @rcollette? This functionality is not supported here afaik, but PRs are welcome.

@rcollette
Copy link
Author

@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.

{
  signedUrl: ""
  iamSessionToken: ""
}

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,
    });
  }

@jakubzitny
Copy link
Collaborator

If the signedUrl is not working for you, you can work around it using customAuthMethod and signResponseHandler, read more about it here.

@rcollette
Copy link
Author

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.

@jakubzitny
Copy link
Collaborator

I see, sorry I didn't realize this. Okay, let's sync with others to see if we can push v3. (#450)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants