Composio 自托管 Helm 部署排障实战Apollo 的 IRSA/S3 静态凭证与社交登录显式禁用【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio本文是面向 Composio 自托管self-hosted / on-premHelm 部署场景的排障指南围绕知识库中两个高频问题展开其一在 AWS EKS 上使用 IRSA / ServiceAccount 凭证访问 S3 时Apollo 容器内不应存在静态 S3 密钥其二自托管环境需要显式禁用 Google/GitHub 社交登录按钮。读完本文你将掌握这两类问题的根因判断、正确的 Helm values 配置、kubectl 调试手段以及 ArgoCD 反复 diff 的消除方法。适用场景与核心组件本文内容适用于采用 Helm 方式部署的 Composio 自托管on-prem环境涉及以下两个关键概念ApolloComposio 自托管部署中的服务组件对应deploy/composio-apollo负责与对象存储、前端配置等基础能力交互。composio-composio-secretsHelm 部署生成的 Kubernetes Secret 对象集中存放服务运行所需的敏感配置如 S3 静态凭证。Apollo ConfigMap由 Helm values 渲染生成的前端/服务配置载体其渲染结果是 ArgoCD 等 GitOps 工具 diff 的对象。文章内容来自知识库公开条目其源文件为 docs/kb/source/platform/self-hosted-helm/public.md对应生成版见 docs/content/kb/guide/platform-self-hosted-helm.mdx并在 docs/kb/manifest.json 中以platform-self-hosted-helm为 slug 注册。以下排障步骤可直接套用。一、Apollo S3 与 IRSA / ServiceAccount 凭证不需要静态 S3 密钥1.1 问题根因静态密钥遮蔽了 IRSA 凭证链在 AWS EKS 上推荐的 S3 访问方式是IRSAIAM Roles for Service Accounts通过给 Pod 的 ServiceAccount 打上eks.amazonaws.com/role-arn注解AWS SDK 会自动从 Pod 的身份换取临时凭证无需在容器里存放任何长期密钥。但 AWS SDK 的凭证解析遵循优先级链当环境变量里存在显式的AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY或本文讨论的S3_ACCESS_KEY_ID/S3_SECRET_ACCESS_KEY时SDK 会优先使用这些静态值而不会回退到 ServiceAccount / IRSA 凭证链。因此只要 Apollo 容器环境中存在这两个变量即便值是占位符也会破坏 IRSA 的自动凭证机制。从知识库描述看对 IRSA / ServiceAccount 方式的 S3 访问S3_ACCESS_KEY_ID和S3_SECRET_ACCESS_KEY不应出现在 Apollo 容器中它们本就是可选密钥。从composio-composio-secrets中移除这两个键后Apollo 会回退到配置的 Pod ServiceAccount / AWS SDK 凭证链。1.2 占位值陷阱dummy-value和字符串null都是真实凭证排障中一个极易踩坑的点是为了让 Secret 非空而填入占位值例如dummy-value字面量字符串null这些占位值会被 AWS SDK 当作真实凭证加载导致 S3 预签名 URLpre-signed URL签名失败典型报错如下InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records. InvalidToken: The provided token is malformed or otherwise invalid.第一个错误说明 Access Key 本身不存在占位值被当作真实 KeyId 使用第二个错误说明签名 Token 非法占位 Secret 无法生成合法签名。两者都是静态凭证遮蔽了 IRSA 凭证链的典型特征。1.3 正确的 Helm values 配置对于 AWS IRSA 场景正确做法是配置 Apollo 的 ServiceAccount 注解与对象存储后端同时保持静态 S3 凭证密钥缺省apollo: serviceAccount: enabled: true name: composio-apollo annotations: eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME objectStorage: backend: s3配置要点serviceAccount.enabled: true启用专用 ServiceAccount并启用其自动挂载serviceAccount.annotations.eks.amazonaws.com/role-arn指向已配置 S3 访问权限的 IAM Role这是 IRSA 的核心objectStorage.backend: s3声明 Apollo 使用 S3 作为对象存储后端不要在composio-composio-secrets中填充S3_ACCESS_KEY_ID/S3_SECRET_ACCESS_KEY。如果使用的是 Pod / 容器身份凭证而非静态密钥同样可以跳过 Kubernetes Secret 中的凭证字段——知识库明确说明 Helm 存储文档中该 Secret 凭证段可跳过。1.4 调试检查命令部署异常时按以下顺序排查# 检查 Apollo 容器运行时环境中的 S3 / AWS 相关变量 kubectl exec -n composio deploy/composio-apollo -- env | grep -E ^S3_|^AWS_ # 查看 Apollo 最近 200 行日志定位 S3 签名/预签名错误 kubectl logs -n composio deploy/composio-apollo --tail200第一条命令用于确认S3_ACCESS_KEY_ID、S3_SECRET_ACCESS_KEY以及可能的AWS_ACCESS_KEY_ID等是否仍以静态值存在于容器环境——这是判断SDK 是否被静态凭证劫持的最直接证据第二条命令用于捕捉预签名 URL 生成或对象读写时的真实错误堆栈。1.5 修复步骤与预期结果标准修复流程编辑composio-composio-secrets删除S3_ACCESS_KEY_ID与S3_SECRET_ACCESS_KEY两个键而非改为空值或占位值滚动重启 Apollo Pod 使 Secret 变更生效重新执行上节的env检查确认两个变量已完全消失观察 Apollo 日志确认预签名 URL 恢复正常。一个典型的支持排障结论示例知识库给出的参考话术如下This looks like Apollo is still receiving static S3 credential env vars, so the AWS SDK is using those instead of falling back to the ServiceAccount/IRSA credentials. For IRSA, S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY should be absent from the Apollo container. Those secrets are optional; if you remove those keys from composio-composio-secrets, Apollo should use the configured ServiceAccount. Placeholder values like dummy-value or literal null are treated as real credentials and can cause S3 signing errors such as InvalidAccessKeyId or InvalidToken. The immediate fix is to remove S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY from composio-composio-secrets, then confirm the Apollo pod environment no longer includes those values.简言之移除静态密钥 → 确认 Pod 环境不再包含这两个值即完成修复。二、自托管部署显式禁用社交登录2.1 环境变量与 Helm values 的映射前端登录页的 Google/GitHub 社交登录按钮由环境变量NEXT_PUBLIC_DISABLE_SOCIAL_LOGIN控制。对于需要隐藏社交登录的自托管客户需要在 Helm values 中以字符串形式设置覆盖值apollo: nextPublicDisableSocialLogin: true注意这里刻意写成字符串true而非布尔值true。原因在于该变量最终要渲染进 Apollo 生成的 ConfigMap字符串true会渲染出显式值而不是空值/null。2.2 消除 ArgoCD 反复 diff在 GitOps 工作流如 ArgoCD中如果 ConfigMap 渲染出的值是空字符串或null而集群中实际状态与期望状态之间在null 与空字符串之间摇摆就会出现反复 diff、部署永远无法收敛的现象。显式设置为字符串true后生成的 Apollo ConfigMap 渲染出明确的true值期望状态与集群状态一致ArgoCD 不再反复 diff社交登录按钮Google/GitHub从登录页消失。该覆盖可直接应用到自托管部署以解除阻塞无需等待特定 release 版本——知识库原文明确说明该覆盖可直接应用不依赖任何版本承诺。2.3 支持排障结论参考一个典型结论示例NEXT_PUBLIC_DISABLE_SOCIAL_LOGIN controls whether the Google/GitHub social login buttons show up on the frontend login page. For your setup, Id set it explicitly to true in the Helm values override: apollo: nextPublicDisableSocialLogin: true This should make the generated Apollo ConfigMap render the explicit value and stop ArgoCD from diffing null vs empty string immediately. The override above can be applied directly; no release-specific promise is required.三、排障决策速查症状根因修复S3 预签名 URL 报InvalidAccessKeyId/InvalidTokenApollo 容器内存在静态/占位 S3 凭证遮蔽 IRSA 凭证链从composio-composio-secrets移除S3_ACCESS_KEY_ID与S3_SECRET_ACCESS_KEY确认 Pod 环境不再包含这两个变量登录页出现 Google/GitHub 社交登录按钮自托管不应出现NEXT_PUBLIC_DISABLE_SOCIAL_LOGIN未设置或值为空在 Helm values 中以字符串形式设置apollo.nextPublicDisableSocialLogin: trueArgoCD 对 Apollo ConfigMap 反复 diffnull vs 空字符串ConfigMap 渲染值不显式显式设置字符串true避免空值/null 摇摆四、知识库来源与进一步阅读本指南内容出自 Composio 知识库的公开排障条目仓库内对应文件为本文档docs/kb/articles/platform-self-hosted-helm.md源数据source版本docs/kb/source/platform/self-hosted-helm/public.md生成版指南docs/content/kb/guide/platform-self-hosted-helm.mdx知识库文章注册信息slug、来源映射、主题标签docs/kb/manifest.json知识库语义检索索引可检索相关排障条目docs/kb/semantic-index.json与本文主题相邻、可继续深入的知识库文章还包括 平台文件存储S3/对象存储相关 与 平台连接账户凭证/认证相关。若你在自托管 Helm 部署中遇到其他认证或存储问题可从这些条目入手继续排查。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Composio 自托管 Helm 部署排障实战：Apollo 的 IRSA/S3 静态凭证与社交登录显式禁用
Composio 自托管 Helm 部署排障实战Apollo 的 IRSA/S3 静态凭证与社交登录显式禁用【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio本文是面向 Composio 自托管self-hosted / on-premHelm 部署场景的排障指南围绕知识库中两个高频问题展开其一在 AWS EKS 上使用 IRSA / ServiceAccount 凭证访问 S3 时Apollo 容器内不应存在静态 S3 密钥其二自托管环境需要显式禁用 Google/GitHub 社交登录按钮。读完本文你将掌握这两类问题的根因判断、正确的 Helm values 配置、kubectl 调试手段以及 ArgoCD 反复 diff 的消除方法。适用场景与核心组件本文内容适用于采用 Helm 方式部署的 Composio 自托管on-prem环境涉及以下两个关键概念ApolloComposio 自托管部署中的服务组件对应deploy/composio-apollo负责与对象存储、前端配置等基础能力交互。composio-composio-secretsHelm 部署生成的 Kubernetes Secret 对象集中存放服务运行所需的敏感配置如 S3 静态凭证。Apollo ConfigMap由 Helm values 渲染生成的前端/服务配置载体其渲染结果是 ArgoCD 等 GitOps 工具 diff 的对象。文章内容来自知识库公开条目其源文件为 docs/kb/source/platform/self-hosted-helm/public.md对应生成版见 docs/content/kb/guide/platform-self-hosted-helm.mdx并在 docs/kb/manifest.json 中以platform-self-hosted-helm为 slug 注册。以下排障步骤可直接套用。一、Apollo S3 与 IRSA / ServiceAccount 凭证不需要静态 S3 密钥1.1 问题根因静态密钥遮蔽了 IRSA 凭证链在 AWS EKS 上推荐的 S3 访问方式是IRSAIAM Roles for Service Accounts通过给 Pod 的 ServiceAccount 打上eks.amazonaws.com/role-arn注解AWS SDK 会自动从 Pod 的身份换取临时凭证无需在容器里存放任何长期密钥。但 AWS SDK 的凭证解析遵循优先级链当环境变量里存在显式的AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY或本文讨论的S3_ACCESS_KEY_ID/S3_SECRET_ACCESS_KEY时SDK 会优先使用这些静态值而不会回退到 ServiceAccount / IRSA 凭证链。因此只要 Apollo 容器环境中存在这两个变量即便值是占位符也会破坏 IRSA 的自动凭证机制。从知识库描述看对 IRSA / ServiceAccount 方式的 S3 访问S3_ACCESS_KEY_ID和S3_SECRET_ACCESS_KEY不应出现在 Apollo 容器中它们本就是可选密钥。从composio-composio-secrets中移除这两个键后Apollo 会回退到配置的 Pod ServiceAccount / AWS SDK 凭证链。1.2 占位值陷阱dummy-value和字符串null都是真实凭证排障中一个极易踩坑的点是为了让 Secret 非空而填入占位值例如dummy-value字面量字符串null这些占位值会被 AWS SDK 当作真实凭证加载导致 S3 预签名 URLpre-signed URL签名失败典型报错如下InvalidAccessKeyId: The AWS Access Key Id you provided does not exist in our records. InvalidToken: The provided token is malformed or otherwise invalid.第一个错误说明 Access Key 本身不存在占位值被当作真实 KeyId 使用第二个错误说明签名 Token 非法占位 Secret 无法生成合法签名。两者都是静态凭证遮蔽了 IRSA 凭证链的典型特征。1.3 正确的 Helm values 配置对于 AWS IRSA 场景正确做法是配置 Apollo 的 ServiceAccount 注解与对象存储后端同时保持静态 S3 凭证密钥缺省apollo: serviceAccount: enabled: true name: composio-apollo annotations: eks.amazonaws.com/role-arn: arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME objectStorage: backend: s3配置要点serviceAccount.enabled: true启用专用 ServiceAccount并启用其自动挂载serviceAccount.annotations.eks.amazonaws.com/role-arn指向已配置 S3 访问权限的 IAM Role这是 IRSA 的核心objectStorage.backend: s3声明 Apollo 使用 S3 作为对象存储后端不要在composio-composio-secrets中填充S3_ACCESS_KEY_ID/S3_SECRET_ACCESS_KEY。如果使用的是 Pod / 容器身份凭证而非静态密钥同样可以跳过 Kubernetes Secret 中的凭证字段——知识库明确说明 Helm 存储文档中该 Secret 凭证段可跳过。1.4 调试检查命令部署异常时按以下顺序排查# 检查 Apollo 容器运行时环境中的 S3 / AWS 相关变量 kubectl exec -n composio deploy/composio-apollo -- env | grep -E ^S3_|^AWS_ # 查看 Apollo 最近 200 行日志定位 S3 签名/预签名错误 kubectl logs -n composio deploy/composio-apollo --tail200第一条命令用于确认S3_ACCESS_KEY_ID、S3_SECRET_ACCESS_KEY以及可能的AWS_ACCESS_KEY_ID等是否仍以静态值存在于容器环境——这是判断SDK 是否被静态凭证劫持的最直接证据第二条命令用于捕捉预签名 URL 生成或对象读写时的真实错误堆栈。1.5 修复步骤与预期结果标准修复流程编辑composio-composio-secrets删除S3_ACCESS_KEY_ID与S3_SECRET_ACCESS_KEY两个键而非改为空值或占位值滚动重启 Apollo Pod 使 Secret 变更生效重新执行上节的env检查确认两个变量已完全消失观察 Apollo 日志确认预签名 URL 恢复正常。一个典型的支持排障结论示例知识库给出的参考话术如下This looks like Apollo is still receiving static S3 credential env vars, so the AWS SDK is using those instead of falling back to the ServiceAccount/IRSA credentials. For IRSA, S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY should be absent from the Apollo container. Those secrets are optional; if you remove those keys from composio-composio-secrets, Apollo should use the configured ServiceAccount. Placeholder values like dummy-value or literal null are treated as real credentials and can cause S3 signing errors such as InvalidAccessKeyId or InvalidToken. The immediate fix is to remove S3_ACCESS_KEY_ID and S3_SECRET_ACCESS_KEY from composio-composio-secrets, then confirm the Apollo pod environment no longer includes those values.简言之移除静态密钥 → 确认 Pod 环境不再包含这两个值即完成修复。二、自托管部署显式禁用社交登录2.1 环境变量与 Helm values 的映射前端登录页的 Google/GitHub 社交登录按钮由环境变量NEXT_PUBLIC_DISABLE_SOCIAL_LOGIN控制。对于需要隐藏社交登录的自托管客户需要在 Helm values 中以字符串形式设置覆盖值apollo: nextPublicDisableSocialLogin: true注意这里刻意写成字符串true而非布尔值true。原因在于该变量最终要渲染进 Apollo 生成的 ConfigMap字符串true会渲染出显式值而不是空值/null。2.2 消除 ArgoCD 反复 diff在 GitOps 工作流如 ArgoCD中如果 ConfigMap 渲染出的值是空字符串或null而集群中实际状态与期望状态之间在null 与空字符串之间摇摆就会出现反复 diff、部署永远无法收敛的现象。显式设置为字符串true后生成的 Apollo ConfigMap 渲染出明确的true值期望状态与集群状态一致ArgoCD 不再反复 diff社交登录按钮Google/GitHub从登录页消失。该覆盖可直接应用到自托管部署以解除阻塞无需等待特定 release 版本——知识库原文明确说明该覆盖可直接应用不依赖任何版本承诺。2.3 支持排障结论参考一个典型结论示例NEXT_PUBLIC_DISABLE_SOCIAL_LOGIN controls whether the Google/GitHub social login buttons show up on the frontend login page. For your setup, Id set it explicitly to true in the Helm values override: apollo: nextPublicDisableSocialLogin: true This should make the generated Apollo ConfigMap render the explicit value and stop ArgoCD from diffing null vs empty string immediately. The override above can be applied directly; no release-specific promise is required.三、排障决策速查症状根因修复S3 预签名 URL 报InvalidAccessKeyId/InvalidTokenApollo 容器内存在静态/占位 S3 凭证遮蔽 IRSA 凭证链从composio-composio-secrets移除S3_ACCESS_KEY_ID与S3_SECRET_ACCESS_KEY确认 Pod 环境不再包含这两个变量登录页出现 Google/GitHub 社交登录按钮自托管不应出现NEXT_PUBLIC_DISABLE_SOCIAL_LOGIN未设置或值为空在 Helm values 中以字符串形式设置apollo.nextPublicDisableSocialLogin: trueArgoCD 对 Apollo ConfigMap 反复 diffnull vs 空字符串ConfigMap 渲染值不显式显式设置字符串true避免空值/null 摇摆四、知识库来源与进一步阅读本指南内容出自 Composio 知识库的公开排障条目仓库内对应文件为本文档docs/kb/articles/platform-self-hosted-helm.md源数据source版本docs/kb/source/platform/self-hosted-helm/public.md生成版指南docs/content/kb/guide/platform-self-hosted-helm.mdx知识库文章注册信息slug、来源映射、主题标签docs/kb/manifest.json知识库语义检索索引可检索相关排障条目docs/kb/semantic-index.json与本文主题相邻、可继续深入的知识库文章还包括 平台文件存储S3/对象存储相关 与 平台连接账户凭证/认证相关。若你在自托管 Helm 部署中遇到其他认证或存储问题可从这些条目入手继续排查。【免费下载链接】composioComposio powers 1000 toolkits, tool search, context management, authentication, and a sandboxed workbench to help you build AI agents that turn intent into action.项目地址: https://gitcode.com/GitHub_Trending/co/composio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考