make sure core generates jwks #2278

Merged

mfreeman451 merged 1 commit from refs/pull/2278/head into main

2025-10-05 18:06:06 +00:00

mfreeman451 commented

2025-10-05 18:04:55 +00:00

(Migrated from github.com)

Owner

Imported from GitHub pull request.

Original GitHub pull request: #1706
Original author: @mfreeman451
Original URL: https://github.com/carverauto/serviceradar/pull/1706
Original created: 2025-10-05T18:04:55Z
Original updated: 2025-10-05T18:06:08Z
Original head: carverauto/serviceradar:k8s/kong_config_jwks
Original base: main
Original merged: 2025-10-05T18:06:06Z by @mfreeman451

PR Type

Enhancement

Description

Add RS256 JWT key generation for Core JWKS
Ensure JWT private key exists in configuration
Minor whitespace cleanup in ConfigMap

Diagram Walkthrough

flowchart LR
  A["ConfigMap Script"] --> B["Check JWT Private Key"]
  B --> C["Generate RS256 Keys"]
  C --> D["Core JWKS Ready"]

File Walkthrough

Relevant files

Enhancement

configmap.yaml

Add RS256 JWT key generation logic

k8s/demo/base/configmap.yaml

Add JWT private key existence check using jq
Generate RS256 keys with serviceradar-cli if missing
Include error handling for key generation failures
Clean up trailing whitespace

+13/-2

Imported from GitHub pull request. Original GitHub pull request: #1706 Original author: @mfreeman451 Original URL: https://github.com/carverauto/serviceradar/pull/1706 Original created: 2025-10-05T18:04:55Z Original updated: 2025-10-05T18:06:08Z Original head: carverauto/serviceradar:k8s/kong_config_jwks Original base: main Original merged: 2025-10-05T18:06:06Z by @mfreeman451 --- ### **PR Type** Enhancement ___ ### **Description** - Add RS256 JWT key generation for Core JWKS - Ensure JWT private key exists in configuration - Minor whitespace cleanup in ConfigMap ___ ### Diagram Walkthrough ```mermaid flowchart LR A["ConfigMap Script"] --> B["Check JWT Private Key"] B --> C["Generate RS256 Keys"] C --> D["Core JWKS Ready"] ``` <details> <summary><h3> File Walkthrough</h3></summary> <table><thead><tr><th></th><th align="left">Relevant files</th></tr></thead><tbody><tr><td><strong>Enhancement</strong></td><td><table> <tr> <td> <details> <summary><strong>configmap.yaml</strong><dd><code>Add RS256 JWT key generation logic</code>                                              </dd></summary> <hr> k8s/demo/base/configmap.yaml <ul><li>Add JWT private key existence check using jq<br> <li> Generate RS256 keys with <code>serviceradar-cli</code> if missing<br> <li> Include error handling for key generation failures<br> <li> Clean up trailing whitespace</ul> </details> </td> <td><a href="https://github.com/carverauto/serviceradar/pull/1706/files#diff-f4548beaa0a3a01a46971c82c5647a0f3f49eb38d66dd939d06d19018173fcd6">+13/-2</a>    </td> </tr> </table></td></tr></tr></tbody></table> </details> ___

qodo-code-review[bot] commented

2025-10-05 18:05:11 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR comment.

Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1706#issuecomment-3369224817
Original created: 2025-10-05T18:05:11Z

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
⚪	Private key handling Description: The script generates or ensures presence of a JWT private key in configuration, so ensure the ConfigMap does not embed or log private key material and that the resulting file is stored with restricted permissions to prevent unauthorized access. configmap.yaml [806-815] Referred Code `if command -v serviceradar-cli >/dev/null 2>&1; then if ! jq -e '.auth.jwt_private_key_pem // empty' "$CONFIG_PATH" >/dev/null 2>&1; then echo "Generating RS256 JWT keys for Core JWKS..." if ! serviceradar-cli generate-jwt-keys --file "$CONFIG_PATH" --bits 2048 --force; then echo "Failed to generate RS256 keys" >&2 fi fi else echo "serviceradar-cli not available; skipping RS256 key generation" >&2 fi`
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
⚪	No custom compliance provided Follow the guide to enable custom compliance check.

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

Imported GitHub PR comment. Original author: @qodo-code-review[bot] Original URL: https://github.com/carverauto/serviceradar/pull/1706#issuecomment-3369224817 Original created: 2025-10-05T18:05:11Z --- ## PR Compliance Guide 🔍  Below is a summary of compliance checks for this PR:<br> <table><tbody><tr><td colspan='2'><strong>Security Compliance</strong></td></tr> <tr><td rowspan=1>⚪</td> <td><details><summary><strong>Private key handling </strong></summary><br> <b>Description:</b> The script generates or ensures presence of a JWT private key in configuration, so ensure <br>the ConfigMap does not embed or log private key material and that the resulting file is <br>stored with restricted permissions to prevent unauthorized access.<br> <strong><a href='https://github.com/carverauto/serviceradar/pull/1706/files#diff-f4548beaa0a3a01a46971c82c5647a0f3f49eb38d66dd939d06d19018173fcd6R806-R815'>configmap.yaml [806-815]</a></strong><br> <details open><summary>Referred Code</summary> ```yaml if command -v serviceradar-cli >/dev/null 2>&1; then if ! jq -e '.auth.jwt_private_key_pem // empty' "$CONFIG_PATH" >/dev/null 2>&1; then echo "Generating RS256 JWT keys for Core JWKS..." if ! serviceradar-cli generate-jwt-keys --file "$CONFIG_PATH" --bits 2048 --force; then echo "Failed to generate RS256 keys" >&2 fi fi else echo "serviceradar-cli not available; skipping RS256 key generation" >&2 fi ``` </details></details></td></tr> <tr><td colspan='2'><strong>Ticket Compliance</strong></td></tr> <tr><td>⚪</td><td><details><summary>🎫 <strong>No ticket provided </summary></strong> - [ ] Create ticket/issue  </details></td></tr> <tr><td colspan='2'><strong>Codebase Duplication Compliance</strong></td></tr> <tr><td>⚪</td><td><details><summary><strong>Codebase context is not defined </strong></summary> Follow the <a href='https://qodo-merge-docs.qodo.ai/core-abilities/rag_context_enrichment/'>guide</a> to enable codebase context checks. </details></td></tr> <tr><td colspan='2'><strong>Custom Compliance</strong></td></tr> <tr><td>⚪</td><td><details><summary><strong>No custom compliance provided</strong></summary> Follow the <a href='https://qodo-merge-docs.qodo.ai/tools/compliance/'>guide</a> to enable custom compliance check. </details></td></tr> <tr><td align="center" colspan="2">   </td></tr></tbody></table> <details><summary>Compliance status legend</summary> 🟢 - Fully Compliant<br> 🟡 - Partial Compliant<br> 🔴 - Not Compliant<br> ⚪ - Requires Further Human Verification<br> 🏷️ - Compliance label<br> </details>

qodo-code-review[bot] commented

2025-10-05 18:06:04 +00:00

(Migrated from github.com)

Author

Owner

Imported GitHub PR comment.

Original author: @qodo-code-review[bot]
Original URL: https://github.com/carverauto/serviceradar/pull/1706#issuecomment-3369225406
Original created: 2025-10-05T18:06:04Z

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
High-level	Generate cryptographic keys before deployment To prevent token invalidation on pod restarts, generate the JWT private key during the deployment pipeline instead of at container startup. The key should then be injected into the pod as a persistent Kubernetes Secret. Examples: k8s/demo/base/configmap.yaml [807-815] `if ! jq -e '.auth.jwt_private_key_pem // empty' "$CONFIG_PATH" >/dev/null 2>&1; then echo "Generating RS256 JWT keys for Core JWKS..." if ! serviceradar-cli generate-jwt-keys --file "$CONFIG_PATH" --bits 2048 --force; then echo "Failed to generate RS256 keys" >&2 fi fi else echo "serviceradar-cli not available; skipping RS256 key generation" >&2 fi` Solution Walkthrough: Before: `# In container startup script (configmap.yaml) CONFIG_PATH="/var/lib/serviceradar/core.json" # Check if JWT private key exists in the config file on an ephemeral volume if ! jq -e '.auth.jwt_private_key_pem' "$CONFIG_PATH"; then # If not, generate a new key. This happens on every pod restart. echo "Generating RS256 JWT keys..." serviceradar-cli generate-jwt-keys --file "$CONFIG_PATH" fi # ... pod continues running with the newly generated key` After: `# 1. In CI/CD pipeline (pre-deployment) # Generate key once and create a Kubernetes Secret openssl genrsa -out private.pem 2048 kubectl create secret generic jwt-private-key --from-file=private.pem # 2. In Deployment/Pod manifest # Mount the secret as a volume spec: containers: - name: my-app volumeMounts: - name: jwt-key-volume mountPath: "/etc/jwt" readOnly: true volumes: - name: jwt-key-volume secret: secretName: jwt-private-key` Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies a critical design flaw where ephemeral JWT keys are generated at container startup, leading to token invalidation on every pod restart, which severely impacts authentication stability.	High
Possible issue	Exit script on key generation failure Add `exit 1` after the error message for key generation failure to prevent the application from starting with an incomplete configuration. k8s/demo/base/configmap.yaml [809-811] `if ! serviceradar-cli generate-jwt-keys --file "$CONFIG_PATH" --bits 2048 --force; then echo "Failed to generate RS256 keys" >&2 + exit 1 fi` Apply / Chat Suggestion importance[1-10]: 9 __ Why: The suggestion correctly identifies a critical flaw where the script continues after a key generation failure, which would lead to a misconfigured and broken application state. Exiting on failure is the correct approach.	High
More

Imported GitHub PR comment. Original author: @qodo-code-review[bot] Original URL: https://github.com/carverauto/serviceradar/pull/1706#issuecomment-3369225406 Original created: 2025-10-05T18:06:04Z --- ## PR Code Suggestions ✨  Explore these optional code suggestions: <table><thead><tr><td><strong>Category</strong></td><td align=left><strong>Suggestion                                                                                                                                    </strong></td><td align=center><strong>Impact</strong></td></tr><tbody><tr><td rowspan=1>High-level</td> <td> <details><summary>Generate cryptographic keys before deployment</summary> ___ **To prevent token invalidation on pod restarts, generate the JWT private key <br>during the deployment pipeline instead of at container startup. The key should <br>then be injected into the pod as a persistent Kubernetes Secret.** ### Examples: <details> <summary> <a href="https://github.com/carverauto/serviceradar/pull/1706/files#diff-f4548beaa0a3a01a46971c82c5647a0f3f49eb38d66dd939d06d19018173fcd6R807-R815">k8s/demo/base/configmap.yaml [807-815]</a> </summary> ```yaml if ! jq -e '.auth.jwt_private_key_pem // empty' "$CONFIG_PATH" >/dev/null 2>&1; then echo "Generating RS256 JWT keys for Core JWKS..." if ! serviceradar-cli generate-jwt-keys --file "$CONFIG_PATH" --bits 2048 --force; then echo "Failed to generate RS256 keys" >&2 fi fi else echo "serviceradar-cli not available; skipping RS256 key generation" >&2 fi ``` </details> ### Solution Walkthrough: #### Before: ```yaml # In container startup script (configmap.yaml) CONFIG_PATH="/var/lib/serviceradar/core.json" # Check if JWT private key exists in the config file on an ephemeral volume if ! jq -e '.auth.jwt_private_key_pem' "$CONFIG_PATH"; then # If not, generate a new key. This happens on every pod restart. echo "Generating RS256 JWT keys..." serviceradar-cli generate-jwt-keys --file "$CONFIG_PATH" fi # ... pod continues running with the newly generated key ``` #### After: ```yaml # 1. In CI/CD pipeline (pre-deployment) # Generate key once and create a Kubernetes Secret openssl genrsa -out private.pem 2048 kubectl create secret generic jwt-private-key --from-file=private.pem # 2. In Deployment/Pod manifest # Mount the secret as a volume spec: containers: - name: my-app volumeMounts: - name: jwt-key-volume mountPath: "/etc/jwt" readOnly: true volumes: - name: jwt-key-volume secret: secretName: jwt-private-key ``` <details><summary>Suggestion importance[1-10]: 9</summary> __ Why: The suggestion correctly identifies a critical design flaw where ephemeral JWT keys are generated at container startup, leading to token invalidation on every pod restart, which severely impacts authentication stability. </details></details></td><td align=center>High </td></tr><tr><td rowspan=1>Possible issue</td> <td> <details><summary>Exit script on key generation failure</summary> ___ **Add <code>exit 1</code> after the error message for key generation failure to prevent the <br>application from starting with an incomplete configuration.** [k8s/demo/base/configmap.yaml [809-811]](https://github.com/carverauto/serviceradar/pull/1706/files#diff-f4548beaa0a3a01a46971c82c5647a0f3f49eb38d66dd939d06d19018173fcd6R809-R811) ```diff if ! serviceradar-cli generate-jwt-keys --file "$CONFIG_PATH" --bits 2048 --force; then echo "Failed to generate RS256 keys" >&2 + exit 1 fi ``` - [ ] **Apply / Chat**  <details><summary>Suggestion importance[1-10]: 9</summary> __ Why: The suggestion correctly identifies a critical flaw where the script continues after a key generation failure, which would lead to a misconfigured and broken application state. Exiting on failure is the correct approach. </details></details></td><td align=center>High </td></tr> <tr><td align="center" colspan="2"> - [ ] More  </td><td></td></tr></tbody></table>