Repository navigation
feat(quoter-bot:PLA-3840): render the runtime Secret from AWS Secrets Manager via ESO - #1
Conversation
… Manager via ESO Co-Authored-By: florian <florian.pautot@gmail.com>
|
I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".
|
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
This repository isn't accepting pull requests at this time. |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| apiVersion: external-secrets.io/v1 | ||
| kind: SecretStore | ||
| metadata: | ||
| name: {{ include "quoter-bot.fullname" . }}-aws |
There was a problem hiding this comment.
🟡 Long release names block secret sync
For a fullname over 59 characters, SecretStore adds -aws without shortening the name. Kubernetes rejects the resource, blocking installation of the runtime Secret.
Learn more
The fullname helper permits names up to 63 characters, while a Kubernetes SecretStore name must also fit within 63 characters. The same overlong value appears in secretStoreRef. The runtime Secret already uses a bounded, hashed name helper.
Example: With a 63-character fullname, appending -aws produces a 67-character SecretStore name. Kubernetes rejects it instead of creating the store.
Recommended fix: Add a bounded, hash-suffixed SecretStore name helper and use it for both the SecretStore metadata name and the ExternalSecret's secretStoreRef.name.
Was this helpful? React with 👍 or 👎 to provide feedback.
| auth: | ||
| jwt: | ||
| serviceAccountRef: | ||
| name: {{ include "quoter-bot.serviceAccountName" . | quote }} |
There was a problem hiding this comment.
🔴 Pod Identity cannot sync runtime secrets
With EKS Pod Identity alone, auth.jwt.serviceAccountRef attempts web-identity authentication rather than using the bot pod's credentials. ESO runs in another pod, so the SecretStore cannot use the bot's Pod Identity association.
Learn more
A SecretStore runs in External Secrets Operator, not in the bot pod. JWT service-account authentication uses a requested service-account token for a web-identity exchange with AWS STS. An EKS Pod Identity association supplies container credentials to pods using the account, not a web-identity role ARN on the ServiceAccount. The chart advertises both IRSA and EKS Pod Identity as compatible identities in runtime Secret setup.
Example: An operator associates the chart's ServiceAccount with an IAM role using EKS Pod Identity and enables externalSecret. The bot can receive Pod Identity credentials, but ESO cannot use that association through auth.jwt; the runtime Secret never syncs and the bot remains unable to start with its required environment.
Recommended fix: Either restrict this SecretStore configuration and documentation to IRSA with a service-account role annotation, or implement an ESO-supported Pod Identity authentication mode and document the required identity of the ESO controller.
Was this helpful? React with 👍 or 👎 to provide feedback.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 9a7c008536
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| auth: | ||
| jwt: | ||
| serviceAccountRef: | ||
| name: {{ include "quoter-bot.serviceAccountName" . | quote }} |
There was a problem hiding this comment.
When this chart is deployed with EKS Pod Identity as the README permits, auth.jwt.serviceAccountRef does not use that association: ESO obtains a projected token for the referenced service account and performs the IRSA web-identity flow, which requires the IRSA role annotation and trust policy. Pod Identity instead supplies container credentials to the ESO controller pod and has no service-account role annotation, so the SecretStore cannot authenticate and the runtime Secret is never created. Restrict this mode to IRSA or provide a separate Pod Identity-compatible authentication path.
Useful? React with 👍 / 👎.
| creationPolicy: Owner | ||
| deletionPolicy: Retain |
There was a problem hiding this comment.
If externalSecret.enabled is later disabled or the ExternalSecret is otherwise removed, creationPolicy: Owner places an owner reference on the generated Secret, so Kubernetes garbage collection deletes it with the ExternalSecret despite deletionPolicy: Retain. That deletion policy only governs what happens when the provider-side secret disappears. Consequently, a migration that disables this feature and references the supposedly retained runtime Secret through envFrom leaves the replacement pod unable to start; use creationPolicy: Orphan if retention on ExternalSecret removal is intended, or remove the retention claim.
Useful? React with 👍 / 👎.
1 participant
Summary
Chart 0.4.0 adds an opt-in path for the runtime environment Secret (Better Stack, OTEL, RPC overrides…) to come from AWS Secrets Manager through External Secrets Operator, instead of a hand-applied
kubectlSecret referenced viaenvFrom. First of four PRs for PLA-3840 (the others wire the tools account / ArgoCD side in morpho-infra).When enabled the chart renders, all keyed on
<fullname>:SecretStore <fullname>-aws— AWS provider,auth.jwt.serviceAccountRef= the chart ServiceAccount. ESO fetches with the bot's own IRSA role, so no new IAM identity; the role only needssecretsmanager:GetSecretValue/DescribeSecretonremoteKeyandkms:Decryptvia Secrets Manager.fails ifserviceAccount.createis off orremoteKey/regionare empty.ExternalSecret <fullname>-runtime→ Secret<fullname>-runtime(creationPolicy: Owner,deletionPolicy: Retain,dataFrom.extract).envFromgetssecretRef: <fullname>-runtimeappended after the user's entries, and the StatefulSet metadata carriessecret.reloader.stakater.com/reload: <fullname>-runtimeso Stakater Reloader restarts the pod on rotation (env is captured at container start).With
enabled: false(default) the render is byte-identical to 0.3.0 apart from the chart version label.Linear: https://linear.app/morpho-labs/issue/PLA-3840
Link to Devin session: https://app.devin.ai/sessions/8e947bded0424c8c95aef54c5aded831
Open in Devin Desktop: https://app.devin.ai/desktop/session/8e947bded0424c8c95aef54c5aded831?variant=devin
Requested by: @0x666c6f