#10670: Add AGENTS.md for AI coding assistant guidance - #1104
#10670: Add AGENTS.md for AI coding assistant guidance#1104chetankh239 wants to merge 4 commits into
Conversation
WalkthroughAdded repository and subsystem-specific ChangesRepository Development Guidance
Estimated code review effort: 1 (Trivial) | ~5 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@AGENTS.md`:
- Line 90: Update the workflow reference in AGENTS.md to use the complete path
`.github/workflows/chart-lint-publish.yml`, matching the existing fully
qualified references for the other workflows.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
Addresses mosip/mosip-config#10670 — provides repository overview, tech stack, build/test commands, and contribution notes for AI agents and contributors working in this repo. Signed-off-by: Chetan Kumar Hirematha <chetankumar.h.239@gmail.com>
c652ec3 to
d570bb2
Compare
Addresses mosip/mosip-config#10670 — extends the existing root AGENTS.md into a hub/index and adds per-subfolder guides matching the tree pattern used in id-repository and partner-management-services: - AGENTS.md: added a Guide index table and repository layout tree linking to each subfolder guide. - db_scripts/AGENTS.md: fresh mosip_toolkit DB install (deploy.sh, init_db.sh cluster install), schema-change workflow, agent rules. - db_upgrade_scripts/AGENTS.md: versioned upgrade/rollback SQL (upgrade.sh), adding a new version step, agent rules. - helm/AGENTS.md: compliance-toolkit Helm chart and cluster install scripts (install.sh, keycloak-init.sh, restart.sh, delete.sh). Signed-off-by: Chetan Kumar Hirematha <chetankumar.h.239@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@AGENTS.md`:
- Line 119: Update the schema-change guidance in AGENTS.md so the upgrade and
rollback script requirement applies only when the change must reach an
already-deployed environment; clarify that fresh-install-only changes need the
DDL/DML under db_scripts/mosip_toolkit/ but do not require entries under
db_upgrade_scripts/.
In `@db_scripts/AGENTS.md`:
- Around line 59-60: Document the runtime secret-injection workflow
consistently: in db_scripts/AGENTS.md lines 59-60, replace the instruction to
edit init_values.yaml with using init_db.sh to read the postgres namespace’s
db-common-secrets and inject dbUserPasswords.dbuserPassword via Helm --set; in
db_scripts/AGENTS.md lines 82-82, state that init_db.sh performs the injection
and the placeholder remains unchanged; in AGENTS.md lines 95-95, describe the
--set override instead of requiring local file modification.
In `@db_upgrade_scripts/AGENTS.md`:
- Line 13: Update the CI statement in AGENTS.md to clarify that db-test.yml
validates only db_scripts/**, specifically db_scripts/mosip_toolkit, and does
not validate db_upgrade_scripts/. Remove the implication that both folders are
covered, while retaining guidance to keep them consistent for schema changes.
In `@helm/AGENTS.md`:
- Around line 78-79: Update the guidance in AGENTS.md to distinguish
non-sensitive environment-specific hosts from credentials: hosts may use
values.yaml, --set, or ConfigMaps, but Keycloak and reCAPTCHA secrets must be
stored only in Kubernetes Secrets or an approved external-secret mechanism,
never in --set, values.yaml, or ConfigMaps.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 6d619070-0003-49f9-9691-5665345080dc
📒 Files selected for processing (4)
AGENTS.mddb_scripts/AGENTS.mddb_upgrade_scripts/AGENTS.mdhelm/AGENTS.md
| 1. Hardcode environment-specific hosts/secrets into chart templates — pass them via `values.yaml` or `--set`/ConfigMap, as `install.sh` and `keycloak-init.sh` already do. | ||
| 2. Commit real reCAPTCHA keys or Keycloak client secrets — `keycloak-init.sh` prompts for them interactively and stores them as Kubernetes Secrets, not in this repo. |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Keep secrets out of --set, values.yaml, and ConfigMaps.
Line 78 groups non-sensitive hosts and secrets under the same delivery mechanisms. --set values can appear in process arguments or Helm release metadata, and ConfigMaps are not secret stores. Store credentials only in Kubernetes Secrets or an approved external-secret mechanism. This protects Keycloak and reCAPTCHA credentials and supports MOSIP security compliance.
Proposed documentation fix
- Hardcode environment-specific hosts/secrets into chart templates — pass them via `values.yaml` or `--set`/ConfigMap, as `install.sh` and `keycloak-init.sh` already do.
+ Do not hardcode environment-specific hosts into chart templates. Pass non-sensitive hosts through `values.yaml`, `--set`, or ConfigMaps. Store credentials only in Kubernetes Secrets or an approved external-secret mechanism; do not commit them to `values.yaml`, pass them with `--set`, or store them in ConfigMaps.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@helm/AGENTS.md` around lines 78 - 79, Update the guidance in AGENTS.md to
distinguish non-sensitive environment-specific hosts from credentials: hosts may
use values.yaml, --set, or ConfigMaps, but Keycloak and reCAPTCHA secrets must
be stored only in Kubernetes Secrets or an approved external-secret mechanism,
never in --set, values.yaml, or ConfigMaps.
- Make the db_upgrade_scripts requirement conditional on reaching an already-deployed environment, not every schema change - Fix db_scripts/AGENTS.md and root AGENTS.md: init_db.sh injects the DB password via Helm --set from the postgres namespace's db-common-secrets cluster secret, it does not read it from init_values.yaml (that field is commented out and must stay that way) — the previous wording could have led someone to uncomment and commit a real password - Fix db_upgrade_scripts/AGENTS.md: db-test.yml only validates db_scripts/mosip_toolkit (triggers on db_scripts/** only), it does not run against this folder — this line contradicted the correct statement already present later in the same file - Fix helm/AGENTS.md: stop grouping secrets with values.yaml/--set/ ConfigMap in the Do-not guidance; secrets belong only in Kubernetes Secrets, which contradicted the correct statement on the very next line Signed-off-by: Chetan Kumar Hirematha <chetankumar.h.239@gmail.com>
"Sensor Biometric Interface" was wrong. Per MOSIP's own docs (docs.mosip.io/develop/biometrics/secure-biometric-interface), SBI is the Secure Biometric Interface — a protocol for biometric capture devices to expose capabilities and perform trusted capture for registration/authentication client apps. Signed-off-by: Chetan Kumar Hirematha <chetankumar.h.239@gmail.com>
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@db_scripts/AGENTS.md`:
- Around line 62-67: Replace the plaintext password injection workflow with the
chart-supported Kubernetes Secret/external-secret reference pattern: in
db_scripts/AGENTS.md lines 62-67, document Secret-reference installation without
reading or passing the password via Helm --set; update db_scripts/AGENTS.md line
87 to remove the agent rule instructing --set password injection; and update
AGENTS.md line 95 to describe the Secret-reference workflow instead of Helm
--set injection.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 72bc9635-a014-4759-abf0-8c322cdade5f
📒 Files selected for processing (4)
AGENTS.mddb_scripts/AGENTS.mddb_upgrade_scripts/AGENTS.mdhelm/AGENTS.md
| `init_db.sh` prompts for confirmation, then reads the app DB user's password from the `postgres` | ||
| namespace's `db-common-secrets` cluster secret and passes it to the chart via `--set | ||
| dbUserPasswords.dbuserPassword="$DB_USER_PASSWORD"` — it does **not** read the password from | ||
| `init_values.yaml` (that field is commented out there and unused; leave it that way, do not | ||
| uncomment and fill it in). It then installs/reinstalls the `postgres-init-toolkit` Helm release in | ||
| the `compliance-toolkit` namespace, overwriting any existing `mosip_toolkit` DB — back it up first |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | 🏗️ Heavy lift
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== files =="
git ls-files | rg '(^|/)AGENTS\.md$|db_scripts/(AGENTS\.md|init_db\.sh|init_values\.yaml)$'
echo
echo "== relevant db_scripts references =="
if [ -f db_scripts/AGENTS.md ]; then
sed -n '55,92p' db_scripts/AGENTS.md | cat -n
fi
echo
echo "== root AGENTS reference =="
if [ -f AGENTS.md ]; then
sed -n '88,100p' AGENTS.md | cat -n
fi
echo
echo "== init_db.sh outline/search =="
if [ -f db_scripts/init_db.sh ]; then
wc -l db_scripts/init_db.sh
rg -n "DB_USER_PASSWORD|db-common-secrets|dbUserPasswords|helm|values|postgres-init-toolkit|mosip_toolkit" db_scripts/init_db.sh
sed -n '1,240p' db_scripts/init_db.sh | cat -n
fi
echo
echo "== init_values password field =="
if [ -f db_scripts/init_values.yaml ]; then
rg -n "dbUserPasswords|dbuserPassword" db_scripts/init_values.yaml -C 3
fi
echo
echo "== occurrences across repo =="
rg -n "dbUserPasswords|dbuserPassword|db-common-secrets|init_db.sh|postgres-init-toolkit" -SRepository: mosip/mosip-compliance-toolkit
Length of output: 6747
🌐 Web query:
Helm --set values plaintext values.yaml secret recommendation environment variable Kubernetes secrets
💡 Result:
Using Helm --set or values.yaml to provide plaintext secrets is strongly discouraged because these values are often committed to version control, stored in plaintext within the Helm release secret inside Kubernetes, and echoed in CI/CD logs [1][2][3][4]. For secure secret management in Kubernetes using Helm, follow these industry-standard approaches: 1. Use External Secrets Management This is the recommended approach for production environments [2][3][5]. Tools like the External Secrets Operator (ESO), HashiCorp Vault, or cloud-native managers (AWS Secrets Manager, Azure Key Vault, etc.) allow you to store secrets outside your cluster [2][6][5]. Your Helm chart should simply reference the name of the secret or the external resource, rather than the sensitive content itself [1][2][7]. Example of referencing a pre-existing secret: env: - name: DB_PASSWORD valueFrom: secretKeyRef: name: {{.Values.secretName }} # Reference the secret name, not the value key: password 2. Encrypt Values Files (GitOps Approach) If you must store secrets in your repository, use an encryption tool like SOPS (often used with the helm-secrets plugin) or Sealed Secrets [6][8][9][4]. - helm-secrets/SOPS: Encrypts your values files at rest. The values are decrypted on the fly during deployment [6][8][4]. - Sealed Secrets: Allows you to commit an encrypted 'SealedSecret' resource to your repository, which is then decrypted by a controller inside your cluster [9]. 3. Development vs. Production While hardcoding secrets in values.yaml is sometimes seen in local development for convenience, it is a significant security risk [2][5]. If you adopt this for local use, ensure these files are excluded from version control (e.g., via.gitignore) and never used in shared environments [5][4]. Summary of Recommendations: - Do not use --set or values.yaml for plaintext secrets [1][2]. - Externalize secrets using Operators (e.g., ESO) to pull from secure vaults [1][2][5]. - Use file encryption (SOPS/Sealed Secrets) if secrets must be managed via GitOps [6][8][9]. - Always use secretKeyRef in your Pod templates to mount secrets as environment variables [1][7][10].
Citations:
- 1: https://safeguard.sh/resources/blog/helm-chart-security-best-practices
- 2: https://www.systemshardening.com/articles/cicd/helm-values-hardening/
- 3: https://blog.gitguardian.com/how-to-handle-secrets-in-helm/
- 4: https://cthfm-k8s.gitbook.io/kubernetes/infrastructure-as-code/helm/managing-secrets-with-helm-and-helm-secrets
- 5: https://docs.raven.io/essentials/secrets-management
- 6: https://github.com/jkroepke/helm-secrets?tab=readme-ov-file
- 7: https://www.baeldung.com/ops/helm-chart-kubernetes-secret-reference
- 8: https://oneuptime.com/blog/post/2026-01-17-helm-secrets-sops-encryption/view
- 9: https://tekkix.com/articles/security/2024/09/kubernetes-secrets-management-with-sealed-se
- 10: https://kubernetes.io/docs/concepts/configuration/secret/
Remove plaintext database credentials from the Helm value path.
db_scripts/init_db.sh reads db-common-secrets, decrypts db-dbuser-password, and passes it with --set dbUserPasswords.dbuserPassword="$DB_USER_PASSWORD". Helm releases may store values in Kubernetes, and process arguments/logs can expose the password. Use the chart’s supported Kubernetes Secret/external-secret reference pattern instead, and update all three documented sites that describe this same workflow.
db_scripts/AGENTS.md: change the install flow to use only a Secret reference, not--set dbUserPasswords.dbuserPassword="$DB_USER_PASSWORD".db_scripts/AGENTS.mdagent rule: stop instructing--setinjection of the DB user password.AGENTS.md: replace the root-level description of Helm--setinjection with the Secret-reference workflow.
📍 Affects 2 files
db_scripts/AGENTS.md#L62-L67(this comment)db_scripts/AGENTS.md#L87-L87AGENTS.md#L95-L95
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@db_scripts/AGENTS.md` around lines 62 - 67, Replace the plaintext password
injection workflow with the chart-supported Kubernetes Secret/external-secret
reference pattern: in db_scripts/AGENTS.md lines 62-67, document
Secret-reference installation without reading or passing the password via Helm
--set; update db_scripts/AGENTS.md line 87 to remove the agent rule instructing
--set password injection; and update AGENTS.md line 95 to describe the
Secret-reference workflow instead of Helm --set injection.
1 participant
Addresses mosip/mosip-config#10670 — provides repository overview, tech stack, build/test commands, and contribution notes for AI agents and contributors working in this repo.
Summary by CodeRabbit