fix(lightspeed): fix rag-content folder ownership in init container

[rm3l]

Manual cherrypick of #3042

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

PR Summary by Qodo

Fix Lightspeed RAG init-container permissions for notebooks on EKS/AKS

🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Copy RAG seed data without preserving restrictive ownership/mode from the image.
• Pre-create the vector_db notebooks directory to prevent sidecar runtime PermissionError.
• Tighten permission changes to only relevant paths instead of blanket chmod 777.

Diagram

graph TD
  RAG["RAG image (/rag)"] --> INIT["Init container"] -->|"cp --no-preserve + mkdir"| VOL[("Shared volume (/data)")] -->|"mounted as /rag-content"| SIDECAR["Lightspeed sidecar"] -->|"writes"| NOTEBOOKS["vector_db/notebooks"]
  subgraph Pod["Backstage/RHDH Pod"]
    INIT
    SIDECAR
    VOL
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Rely on podSecurityContext fsGroup (preferred when possible)

• ➕ Lets Kubernetes apply consistent volume group ownership on mount
• ➕ Avoids broad chmod and reduces permission drift across files
• ➖ May require chart/operator-level securityContext support and validation across clusters
• ➖ Doesn’t help if the source copy preserves restrictive modes/ownership

2. Explicit chown/chgrp the target directories in init container

• ➕ More deterministic than chmod for ownership-related failures
• ➕ Can be scoped to only the needed paths (e.g., notebooks)
• ➖ Requires knowing the runtime UID/GID contract; can break if images/users change
• ➖ May need elevated permissions depending on base image/security policy

3. Use a purpose-built data seeding step (tar/rsync with controlled perms)

• ➕ More control over which metadata is preserved vs normalized
• ➕ Can be faster/more predictable than recursive cp in some cases
• ➖ Adds tooling dependencies (tar/rsync) and operational complexity
• ➖ Overkill for a small amount of seed data

Recommendation: The PR’s approach is a pragmatic, low-risk fix for EKS/AKS: avoid preserving restrictive metadata during the copy, ensure the notebooks directory exists, and apply writeable permissions only where needed. If the deployment stack supports it, adding/using fsGroup at the pod level is the most robust long-term complement, but the current change is an effective minimal backport.

Files changed (5) +5 / -5

Bug fix (3) +3 / -3

rhdh-flavour-lightspeed-config_v1_configmap.yamlFix RAG init-container copy and notebooks permissions +1/-1

Fix RAG init-container copy and notebooks permissions

• Changes the init container to copy RAG data without preserving mode/ownership, pre-creates /data/vector_db/notebooks, and applies writable permissions with a+rwX to the relevant model/vector DB directories.

bundle/rhdh/manifests/rhdh-flavour-lightspeed-config_v1_configmap.yaml

deployment.yamlAlign Lightspeed deployment init-container RAG seeding behavior +1/-1

Align Lightspeed deployment init-container RAG seeding behavior

• Updates the init-container command to use cp --no-preserve=mode,ownership, ensure the notebooks subdirectory exists, and apply scoped writable permissions rather than chmod 777.

config/profile/rhdh/default-config/flavours/lightspeed/deployment.yaml

install.yamlPropagate Lightspeed RAG init-container permission fix to dist install +1/-1

Propagate Lightspeed RAG init-container permission fix to dist install

• Carries the updated init-container command into the rendered distribution install manifest to prevent runtime PermissionError when the sidecar writes under vector_db/notebooks.

dist/rhdh/install.yaml

Other (2) +2 / -2

backstage-operator.clusterserviceversion.yamlRegenerate CSV createdAt timestamp +1/-1

Regenerate CSV createdAt timestamp

• Updates the ClusterServiceVersion metadata createdAt timestamp to reflect a new bundle build.

bundle/backstage.io/manifests/backstage-operator.clusterserviceversion.yaml

backstage-operator.clusterserviceversion.yamlRegenerate RHDH CSV createdAt timestamp +1/-1

Regenerate RHDH CSV createdAt timestamp

• Updates the ClusterServiceVersion metadata createdAt timestamp for the RHDH bundle build.

bundle/rhdh/manifests/backstage-operator.clusterserviceversion.yaml

[rhdh-qodo-merge]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 18 rules

1. GNU-specific cp option 🐞 Bug ☼ Reliability

Description

The init container command uses cp --no-preserve=mode,ownership, which is not POSIX and typically
only available in GNU coreutils; if the rag-content image ever ships a different cp
implementation (e.g., BusyBox), the init container will error and the pod will not start.

Code

config/profile/rhdh/default-config/flavours/lightspeed/deployment.yaml[12]

+            - "echo 'Copying RAG data...'; cp -r --no-preserve=mode,ownership /rag/. /data/ && mkdir -p /data/vector_db/notebooks && chmod -R a+rwX /data/embeddings_model /data/vector_db && echo 'Copy complete.'"

Relevance

⭐⭐ Medium

No prior reviews mention GNU cp portability; Lightspeed initContainer already uses shell cp commands
(PR 2645).

PR-#2645

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The Deployment explicitly runs sh -c with cp -r --no-preserve=mode,ownership ... using the
external rag-content image; --no-preserve is a GNU extension, so this is a portability
dependency introduced by the change.

config/profile/rhdh/default-config/flavours/lightspeed/deployment.yaml[6-23]
dist/rhdh/install.yaml[3283-3305]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The init container uses GNU-specific `cp --no-preserve=...` flags, which may not exist in non-GNU images.

### Issue Context
The image is external (`quay.io/redhat-ai-dev/rag-content:...`), and the manifest does not otherwise guarantee the availability of GNU coreutils `cp`.

### Fix Focus Areas
- config/profile/rhdh/default-config/flavours/lightspeed/deployment.yaml[12-12]
- bundle/rhdh/manifests/rhdh-flavour-lightspeed-config_v1_configmap.yaml[273-273]
- dist/rhdh/install.yaml[3295-3295]

### Suggested direction
Use a more portable copy approach (e.g., plain `cp -R` followed by explicit `chmod`/`chown` as needed), or explicitly ensure the init container image provides GNU coreutils (document/enforce it).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Embeddings made writable 🐞 Bug ⛨ Security

Description

The init container recursively grants write permission to /data/embeddings_model, which makes the
embeddings model artifacts mutable at runtime within the pod even though they are referenced as
model input data.

Code

config/profile/rhdh/default-config/flavours/lightspeed/deployment.yaml[12]

+            - "echo 'Copying RAG data...'; cp -r --no-preserve=mode,ownership /rag/. /data/ && mkdir -p /data/vector_db/notebooks && chmod -R a+rwX /data/embeddings_model /data/vector_db && echo 'Copy complete.'"

Relevance

⭐ Low

Team previously merged permissive chmod in Lightspeed initContainer (chmod -R 777 /data/vector_db)
without security pushback.

PR-#2645

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The init container modifies permissions for /data/embeddings_model and that same volume is mounted
into the main container at /rag-content; the Lightspeed config references
/rag-content/embeddings_model as the model location, so the chmod change directly impacts model
artifacts.

config/profile/rhdh/default-config/flavours/lightspeed/deployment.yaml[6-45]
config/profile/rhdh/default-config/flavours/lightspeed/configmap-files.yaml[190-203]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The init container applies `chmod -R a+rwX` to `/data/embeddings_model`, making model files world-writable inside the pod.

### Issue Context
The Lightspeed configuration references `/rag-content/embeddings_model` as the embedding model location, suggesting the directory is intended primarily for reads (while the vector DB paths are more likely to need writes).

### Fix Focus Areas
- config/profile/rhdh/default-config/flavours/lightspeed/deployment.yaml[12-12]
- bundle/rhdh/manifests/rhdh-flavour-lightspeed-config_v1_configmap.yaml[273-273]
- dist/rhdh/install.yaml[3295-3295]
- config/profile/rhdh/default-config/flavours/lightspeed/configmap-files.yaml[190-203]

### Suggested direction
Split permissions:
- Keep `/data/vector_db` as writable (`a+rwX` or a tighter UID/GID-based approach).
- Make `/data/embeddings_model` read-only (`a+rX`, or `u+rwX,g+rX,o+rX` depending on your runtime UID/GID).
If feasible, consider using `securityContext.fsGroup`/UID-GID ownership instead of world-writable perms.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---