vxcontrol/pentagi
1
0
Fork 0
mirror of https://github.com/vxcontrol/pentagi.git synced 2026-07-21 08:15:23 -04:00
Code Issues 45 Packages Projects Releases 9 Wiki Activity

[PR #90] [MERGED] feat: add support for temporary AWS credentials #151

New Issue
Closed
opened 2026-06-06 22:09:25 -04:00 by yindo · 0 comments
yindo commented 2026-06-06 22:09:25 -04:00
Owner
Copy Link
Copy Source

📋 Pull Request Information

Original PR: https://github.com/vxcontrol/pentagi/pull/90
Author: @kaikreuzer
Created: 12/5/2025
Status: ✅ Merged
Merged: 12/6/2025
Merged by: @asdek

Base: master ← Head: tmpsessions

📝 Commits (1)

  • 2f35b87 feat: add support for temporary AWS credentials

📊 Changes

5 files changed (+12 additions, -6 deletions)

View changed files

📝 .env.example (+1 -0)
📝 backend/docs/config.md (+4 -1)
📝 backend/pkg/config/config.go (+5 -4)
📝 backend/pkg/providers/bedrock/bedrock.go (+1 -1)
📝 docker-compose.yml (+1 -0)

📄 Description

Description of the Change

Problem

PentAGI's AWS Bedrock integration only supported permanent IAM user credentials, making it incompatible with temporary security credentials from AWS STS, assumed roles, or MFA-enabled sessions. This limited deployment flexibility and security best practices.

Solution

Added support for AWS session tokens by introducing a new BEDROCK_SESSION_TOKEN configuration parameter. The session token is passed to AWS SDK's StaticCredentialsProvider, enabling temporary credential workflows while remaining backward compatible with permanent credentials.

Type of Change

  • 🐛 Bug fix (non-breaking change which fixes an issue)
  • 🚀 New feature (non-breaking change which adds functionality)
  • 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • 📚 Documentation update
  • 🔧 Configuration change
  • 🧪 Test update
  • 🛡️ Security update

Areas Affected

  • Core Services (Frontend UI/Backend API)
  • AI Agents (Researcher/Developer/Executor)
  • Security Tools Integration
  • Memory System (Vector Store/Knowledge Base)
  • Monitoring Stack (Grafana/OpenTelemetry)
  • Analytics Platform (Langfuse)
  • External Integrations (LLM/Search APIs)
  • Documentation
  • Infrastructure/DevOps

Testing and Verification

Test Configuration

PentAGI Version: main branch + this PR
Docker Version: Latest
Host OS: macOS/Linux
LLM Provider: AWS Bedrock
Enabled Features: [Bedrock with temporary credentials]

Test Steps

  1. Obtain temporary AWS credentials using aws sts assume-role or aws sts get-session-token
  2. Set BEDROCK_SESSION_TOKEN environment variable with the session token
  3. Configure BEDROCK_ACCESS_KEY_ID and BEDROCK_SECRET_ACCESS_KEY with temporary credentials
  4. Start PentAGI and verify Bedrock provider successfully authenticates
  5. Verify existing setups without session token continue to work

Test Results

  • Bedrock provider successfully authenticates with temporary credentials
  • Backward compatibility maintained for permanent credentials (empty session token)

Security Considerations

Enhancement: Enables use of temporary credentials, which is a security best practice. Temporary credentials automatically expire, reducing risk from credential exposure. Supports MFA-enforced policies and IAM role assumption patterns.

Performance Impact

No performance impact. Session token is only used during authentication initialization.

Documentation Updates

  • README.md updates
  • API documentation updates
  • Configuration documentation updates
  • GraphQL schema updates
  • Other:

Deployment Notes

New Environment Variable: BEDROCK_SESSION_TOKEN (optional)

  • Leave empty for permanent IAM credentials
  • Set when using temporary credentials from STS/assumed roles
  • Add to .env file if using docker-compose deployment

Backward Compatible: Existing deployments continue to work without changes.

Checklist

Code Quality

  • My code follows the project's coding standards
  • I have added/updated necessary documentation
  • I have added tests to cover my changes
  • All new and existing tests pass
  • I have run go fmt and go vet (for Go code)
  • I have run npm run lint (for TypeScript/JavaScript code)

Security

  • I have considered security implications
  • Changes maintain or improve the security model
  • Sensitive information has been properly handled

Compatibility

  • Changes are backward compatible
  • Breaking changes are clearly marked and documented
  • Dependencies are properly updated

Documentation

  • Documentation is clear and complete
  • Comments are added for non-obvious code
  • API changes are documented

Additional Notes

This change enables common AWS deployment patterns:

  • EC2 instances with IAM roles
  • ECS/EKS tasks with task roles
  • Local development with aws-vault or similar tools
  • CI/CD pipelines using assumed roles
  • MFA-protected IAM users

The session token field is optional and backward compatible with existing configurations.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/vxcontrol/pentagi/pull/90 **Author:** [@kaikreuzer](https://github.com/kaikreuzer) **Created:** 12/5/2025 **Status:** ✅ Merged **Merged:** 12/6/2025 **Merged by:** [@asdek](https://github.com/asdek) **Base:** `master` ← **Head:** `tmpsessions` --- ### 📝 Commits (1) - [`2f35b87`](https://github.com/vxcontrol/pentagi/commit/2f35b87dfbb299c7627de94a978eb421beac1dd6) feat: add support for temporary AWS credentials ### 📊 Changes **5 files changed** (+12 additions, -6 deletions) <details> <summary>View changed files</summary> 📝 `.env.example` (+1 -0) 📝 `backend/docs/config.md` (+4 -1) 📝 `backend/pkg/config/config.go` (+5 -4) 📝 `backend/pkg/providers/bedrock/bedrock.go` (+1 -1) 📝 `docker-compose.yml` (+1 -0) </details> ### 📄 Description ### Description of the Change #### Problem PentAGI's AWS Bedrock integration only supported permanent IAM user credentials, making it incompatible with temporary security credentials from AWS STS, assumed roles, or MFA-enabled sessions. This limited deployment flexibility and security best practices. #### Solution Added support for AWS session tokens by introducing a new `BEDROCK_SESSION_TOKEN` configuration parameter. The session token is passed to AWS SDK's `StaticCredentialsProvider`, enabling temporary credential workflows while remaining backward compatible with permanent credentials. ### Type of Change - [ ] 🐛 Bug fix (non-breaking change which fixes an issue) - [x] 🚀 New feature (non-breaking change which adds functionality) - [ ] 💥 Breaking change (fix or feature that would cause existing functionality to not work as expected) - [x] 📚 Documentation update - [x] 🔧 Configuration change - [ ] 🧪 Test update - [ ] 🛡️ Security update ### Areas Affected - [x] Core Services (Frontend UI/Backend API) - [ ] AI Agents (Researcher/Developer/Executor) - [ ] Security Tools Integration - [ ] Memory System (Vector Store/Knowledge Base) - [ ] Monitoring Stack (Grafana/OpenTelemetry) - [ ] Analytics Platform (Langfuse) - [x] External Integrations (LLM/Search APIs) - [x] Documentation - [x] Infrastructure/DevOps ### Testing and Verification #### Test Configuration ```yaml PentAGI Version: main branch + this PR Docker Version: Latest Host OS: macOS/Linux LLM Provider: AWS Bedrock Enabled Features: [Bedrock with temporary credentials] ``` #### Test Steps 1. Obtain temporary AWS credentials using `aws sts assume-role` or `aws sts get-session-token` 2. Set `BEDROCK_SESSION_TOKEN` environment variable with the session token 3. Configure `BEDROCK_ACCESS_KEY_ID` and `BEDROCK_SECRET_ACCESS_KEY` with temporary credentials 4. Start PentAGI and verify Bedrock provider successfully authenticates 5. Verify existing setups without session token continue to work #### Test Results - Bedrock provider successfully authenticates with temporary credentials - Backward compatibility maintained for permanent credentials (empty session token) ### Security Considerations **Enhancement**: Enables use of temporary credentials, which is a security best practice. Temporary credentials automatically expire, reducing risk from credential exposure. Supports MFA-enforced policies and IAM role assumption patterns. ### Performance Impact No performance impact. Session token is only used during authentication initialization. ### Documentation Updates - [x] README.md updates - [ ] API documentation updates - [x] Configuration documentation updates - [ ] GraphQL schema updates - [ ] Other: <!-- specify --> ### Deployment Notes **New Environment Variable**: `BEDROCK_SESSION_TOKEN` (optional) - Leave empty for permanent IAM credentials - Set when using temporary credentials from STS/assumed roles - Add to `.env` file if using docker-compose deployment **Backward Compatible**: Existing deployments continue to work without changes. ### Checklist #### Code Quality - [x] My code follows the project's coding standards - [x] I have added/updated necessary documentation - [ ] I have added tests to cover my changes - [ ] All new and existing tests pass - [x] I have run `go fmt` and `go vet` (for Go code) - [ ] I have run `npm run lint` (for TypeScript/JavaScript code) #### Security - [x] I have considered security implications - [x] Changes maintain or improve the security model - [x] Sensitive information has been properly handled #### Compatibility - [x] Changes are backward compatible - [ ] Breaking changes are clearly marked and documented - [x] Dependencies are properly updated #### Documentation - [x] Documentation is clear and complete - [x] Comments are added for non-obvious code - [ ] API changes are documented ### Additional Notes This change enables common AWS deployment patterns: - EC2 instances with IAM roles - ECS/EKS tasks with task roles - Local development with `aws-vault` or similar tools - CI/CD pipelines using assumed roles - MFA-protected IAM users The session token field is optional and backward compatible with existing configurations. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
yindo added the pull-request label 2026-06-06 22:09:25 -04:00
yindo closed this issue 2026-06-06 22:09:25 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
enhancement
help wanted
pull-request
Mirrored from GitHub Pull Request
 question
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: vxcontrol/pentagi#151
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?