feat: add AWS STS AssumeRole support to AWS credential#5731
feat: add AWS STS AssumeRole support to AWS credential#5731rohan-patil2 wants to merge 1 commit intoFlowiseAI:mainfrom
Conversation
Summary of ChangesHello @rohan-patil2, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly upgrades Flowise's AWS integration by introducing support for AWS STS AssumeRole. This enhancement allows users to configure role-based access, which is crucial for adhering to least-privilege principles and managing temporary credentials in enterprise AWS environments. The changes streamline credential management through a new centralized utility, making AWS authentication more secure, flexible, and aligned with modern cloud security practices, all while maintaining full backward compatibility. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces AWS STS AssumeRole support, which is a significant enhancement for security and authentication flexibility with AWS services. The implementation is robust, featuring a new centralized utility getAWSCredentialConfig that cleanly handles various authentication scenarios. The code is well-documented, and backward compatibility is thoughtfully maintained. The refactoring across multiple AWS nodes greatly simplifies the credential handling logic. I've included a few minor suggestions to enhance type safety, which will improve long-term maintainability. Overall, this is an excellent and well-executed feature.
|
|
||
| const credentialData = await getCredentialData(nodeData.credential ?? '', options) | ||
| const credentialConfig = await getAWSCredentialConfig(nodeData, options, region) | ||
| let clientConfig: any = { region } |
There was a problem hiding this comment.
For improved type safety and code clarity, it's better to use the specific KendraClientConfig type from the AWS SDK instead of any. This helps prevent potential runtime errors and improves maintainability.
You'll need to add KendraClientConfig to your imports:
import { KendraClient, ..., KendraClientConfig } from '@aws-sdk/client-kendra'
| let clientConfig: any = { region } | |
| let clientConfig: KendraClientConfig = { region } |
|
|
||
| const credentialData = await getCredentialData(nodeData.credential ?? '', options) | ||
| const credentialConfig = await getAWSCredentialConfig(nodeData, options, region) | ||
| let clientConfig: any = { region } |
There was a problem hiding this comment.
For improved type safety and code clarity, it's better to use the specific KendraClientConfig type from the AWS SDK instead of any. This helps prevent potential runtime errors and improves maintainability.
You'll need to ensure KendraClientConfig is imported from @aws-sdk/client-kendra.
| let clientConfig: any = { region } | |
| let clientConfig: KendraClientConfig = { region } |
|
|
||
| const credentialData = await getCredentialData(nodeData.credential ?? '', options) | ||
| const credentialConfig = await getAWSCredentialConfig(nodeData, options, region) | ||
| let clientOptions: any = {} |
There was a problem hiding this comment.
The clientOptions object is typed as any. Since it's passed to the AmazonKendraRetriever, which expects a KendraClientConfig, you can type it explicitly for better type safety. Using Partial<KendraClientConfig> is appropriate here since it's initialized as an empty object.
You'll need to ensure KendraClientConfig is imported from @aws-sdk/client-kendra.
| let clientOptions: any = {} | |
| let clientOptions: Partial<KendraClientConfig> = {} |
| const { accessKeyId, secretAccessKey, sessionToken, roleArn, externalId, region } = params | ||
|
|
||
| // Build STS client config | ||
| const stsConfig: Record<string, any> = { region } |
There was a problem hiding this comment.
The stsConfig object is typed as Record<string, any>, which is a bit loose. For better type safety and autocompletion, you can use the STSClientConfig type from the AWS SDK.
You'll need to add STSClientConfig to the existing import from @aws-sdk/client-sts.
| const stsConfig: Record<string, any> = { region } | |
| const stsConfig: STSClientConfig = { region } |
-- Credential version bump (1.0 → 2.0) — The PR description says no migration is needed, but bumping the credential --AWS_REGIONS duplication — This regions list likely already exists elsewhere in the codebase (several AWS nodes define their own region lists). Centralizing it here is good, but only if the nodes are updated to import from awsToolsUtils.ts. If they still maintain their own copies, this adds duplication rather than reducing it. --SDK default chain fallback inconsistency — When getAWSCredentialConfig returns { credentials: undefined }, some nodes check if (credentialConfig.credentials) before assigning, which correctly falls through to the SDK default chain. But in S3Directory.ts the diff shows credentials = credentialConfig.credentials without a guard — if credentials was previously initialized to a non-undefined value, this would overwrite it with undefined. Verify all consumer nodes handle the undefined case consistently. --getAWSCredentials() breaks SDK default chain — The backward-compat wrapper throws "AWS Access Key ID and Secret Access Key are required" when config.credentials is undefined. This means Pattern A nodes (SNS, DynamoDB) can never use the SDK default credential chain (EC2/EKS instance profiles). This may be intentional but should be documented as a known limitation.
|
2 participants
Summary
awsApi), enabling STS AssumeRole authentication across all 9 AWS-integrated nodesgetAWSCredentialConfig()utility that handles static credentials, AssumeRole with explicit keys, and AssumeRole via the SDK default credential chainaws,aws-cn,aws-us-govpartitions)Background
Flowise currently only supports static IAM access keys for AWS authentication. Many organizations require role-based access for cross-account workflows, least-privilege enforcement, and temporary credential rotation. This change adds AssumeRole support so users can enter a Role ARN in the credential form and have Flowise obtain temporary credentials via STS automatically.
Supported Authentication Scenarios
Backward Compatibility
awsApi) is unchanged; no database migration requiredgetAWSCredentials()signature and return type are preservedSecurity
FlowiseSession-{timestamp}) provides CloudTrail audit traceability