Grafana logs, alerting, and dashboards#130
Conversation
|
Warning Review limit reached
Next review available in: 45 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (5)
📝 WalkthroughWalkthroughThe monitoring stack adds Loki storage, Alloy log collection, Grafana dashboards and Discord alerting, TLS ingress routing, HTTP histogram metrics, and deployment workflow validation for the new monitoring components. ChangesMonitoring observability
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant SpringAPI
participant Prometheus
participant Alloy
participant Loki
participant Grafana
SpringAPI->>Prometheus: Expose histogram metrics
Alloy->>Loki: Push labeled pod logs
Grafana->>Prometheus: Query metrics for dashboards and alerts
Grafana->>Loki: Query logs for dashboards
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 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 `@infra/k8s/monitoring/grafana.yaml`:
- Around line 16-22: Add Loki and Alloy Kubernetes manifests under the
monitoring configuration, including the resources required for the `loki`
deployment and `alloy` daemonset referenced by
`.github/workflows/deploy-k8s.yml`, or update the rollout targets and Grafana
datasource configuration to match the resources actually deployed. Ensure the
Loki service resolves as `loki.monitoring.svc.cluster.local:3100`.
🪄 Autofix (Beta)
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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 8dd054f8-a31b-4c93-b664-251517f8305f
📒 Files selected for processing (2)
.github/workflows/deploy-k8s.ymlinfra/k8s/monitoring/grafana.yaml
imol-ai
force-pushed
the
feat/grafana-logs
branch
from
d3d8200 to
bbaca0d
Compare
imol-ai
force-pushed
the
feat/grafana-logs
branch
from
bbaca0d to
a5dde8e
Compare
imol-ai
force-pushed
the
feat/grafana-logs
branch
from
a5dde8e to
ab0e54e
Compare
imol-ai
force-pushed
the
feat/grafana-logs
branch
2 times, most recently
from
730e2ae to
59a808f
Compare
imol-ai
force-pushed
the
feat/grafana-logs
branch
from
59a808f to
4a96eb9
Compare
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 `@infra/k8s/monitoring/alloy.yaml`:
- Around line 135-157: Add a container-level securityContext to the Alloy
container definition, setting runAsNonRoot, runAsUser, readOnlyRootFilesystem,
and allowPrivilegeEscalation: false. Place it alongside the existing image,
args, ports, volumeMounts, and resources fields, using the appropriate non-root
UID supported by the Alloy image.
- Line 137: Update the Grafana Alloy container image under the Kubernetes
monitoring configuration from grafana/alloy:v1.7.1 to the current stable
grafana/alloy:v1.17.1.
In `@infra/k8s/monitoring/loki.yaml`:
- Around line 74-99: Add a container-level securityContext to the loki container
definition, setting runAsNonRoot to true, runAsUser to a non-root UID,
readOnlyRootFilesystem to true, and allowPrivilegeEscalation to false. Keep the
existing volume mounts for writable paths.
- Line 76: The Loki container image is pinned to outdated version 3.4.2 and must
be upgraded. Update the image reference in the Loki deployment to
grafana/loki:v3.6.4 or a newer stable release, preserving the existing image
configuration.
🪄 Autofix (Beta)
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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 85a90264-8ac6-4845-bf6c-6e1a8f520894
📒 Files selected for processing (7)
.github/workflows/deploy-k8s.ymlREADME.mdinfra/k8s/monitoring/alloy.yamlinfra/k8s/monitoring/grafana-ingress.yamlinfra/k8s/monitoring/grafana.yamlinfra/k8s/monitoring/loki.yamlinfra/k8s/monitoring/prometheus.yaml
✅ Files skipped from review due to trivial changes (2)
- infra/k8s/monitoring/prometheus.yaml
- README.md
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/deploy-k8s.yml
| containers: | ||
| - name: alloy | ||
| image: grafana/alloy:v1.7.1 | ||
| args: | ||
| - run | ||
| - /etc/alloy/config.alloy | ||
| - --storage.path=/var/lib/alloy/data | ||
| - --server.http.listen-addr=0.0.0.0:12345 | ||
| ports: | ||
| - name: http | ||
| containerPort: 12345 | ||
| volumeMounts: | ||
| - name: config | ||
| mountPath: /etc/alloy | ||
| - name: data | ||
| mountPath: /var/lib/alloy/data | ||
| resources: | ||
| requests: | ||
| cpu: 30m | ||
| memory: 64Mi | ||
| limits: | ||
| cpu: 100m | ||
| memory: 128Mi |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Add container-level security context to the Alloy container.
The Alloy container has no securityContext. Add runAsNonRoot, runAsUser, readOnlyRootFilesystem, and allowPrivilegeEscalation: false to follow least-privilege principles.
🔒️ Proposed security hardening
- name: alloy
image: grafana/alloy:v1.7.1
+ securityContext:
+ runAsNonRoot: true
+ runAsUser: 10001
+ readOnlyRootFilesystem: true
+ allowPrivilegeEscalation: false
args:📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| containers: | |
| - name: alloy | |
| image: grafana/alloy:v1.7.1 | |
| args: | |
| - run | |
| - /etc/alloy/config.alloy | |
| - --storage.path=/var/lib/alloy/data | |
| - --server.http.listen-addr=0.0.0.0:12345 | |
| ports: | |
| - name: http | |
| containerPort: 12345 | |
| volumeMounts: | |
| - name: config | |
| mountPath: /etc/alloy | |
| - name: data | |
| mountPath: /var/lib/alloy/data | |
| resources: | |
| requests: | |
| cpu: 30m | |
| memory: 64Mi | |
| limits: | |
| cpu: 100m | |
| memory: 128Mi | |
| containers: | |
| - name: alloy | |
| image: grafana/alloy:v1.7.1 | |
| securityContext: | |
| runAsNonRoot: true | |
| runAsUser: 10001 | |
| readOnlyRootFilesystem: true | |
| allowPrivilegeEscalation: false | |
| args: | |
| - run | |
| - /etc/alloy/config.alloy | |
| - --storage.path=/var/lib/alloy/data | |
| - --server.http.listen-addr=0.0.0.0:12345 | |
| ports: | |
| - name: http | |
| containerPort: 12345 | |
| volumeMounts: | |
| - name: config | |
| mountPath: /etc/alloy | |
| - name: data | |
| mountPath: /var/lib/alloy/data | |
| resources: | |
| requests: | |
| cpu: 30m | |
| memory: 64Mi | |
| limits: | |
| cpu: 100m | |
| memory: 128Mi |
🧰 Tools
🪛 Trivy (0.69.3)
[error] 127-157: Default security context configured
deployment alloy in monitoring namespace is using the default security context, which allows root privileges
Rule: KSV-0118
(IaC/Kubernetes)
🤖 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 `@infra/k8s/monitoring/alloy.yaml` around lines 135 - 157, Add a
container-level securityContext to the Alloy container definition, setting
runAsNonRoot, runAsUser, readOnlyRootFilesystem, and allowPrivilegeEscalation:
false. Place it alongside the existing image, args, ports, volumeMounts, and
resources fields, using the appropriate non-root UID supported by the Alloy
image.
Source: Linters/SAST tools
| serviceAccountName: alloy | ||
| containers: | ||
| - name: alloy | ||
| image: grafana/alloy:v1.7.1 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for Alloy security advisories and latest version
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: DOCKER, package: "grafana/alloy") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: AET-DevOps26/team-devsecops
Length of output: 645
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Show the local context around the Alloy image pin
sed -n '125,145p' infra/k8s/monitoring/alloy.yaml
# Check the latest Grafana Alloy release tag from GitHub
gh api repos/grafana/alloy/releases/latest --jq '{tag_name, published_at, draft, prerelease}'
# List recent Alloy releases to see whether v1.7.1 is still current/stable
gh api repos/grafana/alloy/releases --paginate --jq '.[] | select(.prerelease==false and .draft==false) | {tag_name, published_at} ' | head -n 20Repository: AET-DevOps26/team-devsecops
Length of output: 1998
🌐 Web query:
grafana alloy v1.7.1 vulnerabilities GitHub advisory stable release v1.17.1
💡 Result:
As of July 10, 2026, the most recent stable release of Grafana Alloy is v1.17.1, which was published on June 29, 2026 [1]. Regarding the version v1.7.1, it is not a recent release; Grafana Alloy has since progressed significantly in versioning [1][2]. There are no specific GitHub security advisories tied to a "v1.7.1" release of Grafana Alloy in the official security database [3][4]. Security vulnerabilities identified in Grafana Alloy are tracked in the GitHub Advisory Database [3] and disclosed via official Grafana channels [5]. For users managing security, it is recommended to monitor the official Grafana Alloy GitHub repository releases and their associated security advisories [6][7], as well as the official documentation for comprehensive release notes [5]. Past vulnerabilities affecting various versions of Grafana Alloy (such as CVE-2024-8975, CVE-2025-22870, and CVE-2025-29786) have been addressed in subsequent updates [3][8][9]. Always ensure you are running the latest stable release (v1.17.1 as of this date) to benefit from the latest security patches and features [1].
Citations:
- 1: https://github.com/grafana/alloy/releases/tag/v1.17.1
- 2: https://github.com/grafana/alloy/blob/main/CHANGELOG.md
- 3: https://github.com/advisories/GHSA-chqx-36rm-rf8h/dependabot
- 4: https://osv.dev/vulnerability/GHSA-chqx-36rm-rf8h
- 5: https://grafana.com/docs/alloy/latest/release-notes/
- 6: https://github.com/grafana/alloy/releases
- 7: https://github.com/grafana/alloy
- 8: https://security.snyk.io/vuln/SNYK-CHAINGUARDLATEST-GRAFANAALLOY-9480290
- 9: https://security.snyk.io/vuln/SNYK-CHAINGUARDLATEST-GRAFANAALLOY-9464044
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# List the most recent non-draft, non-prerelease release tags for grafana/alloy
gh api repos/grafana/alloy/releases --paginate --jq '.[] | select(.draft==false and .prerelease==false) | [.tag_name, .published_at] | `@tsv`' | head -n 15
# Pull the release metadata for the v1.17.1 tag specifically
gh api repos/grafana/alloy/releases/tags/v1.17.1 --jq '{tag_name, published_at, prerelease, draft}'
# Check whether the repo has an advisory or security alert mentioning grafana/alloy or v1.7.1 in public search results via GitHub code search metadata
gh api search/issues -f q='repo:grafana/alloy "v1.7.1" vulnerability OR advisory OR CVE' --jq '.items[] | {title, html_url, created_at}'Repository: AET-DevOps26/team-devsecops
Length of output: 610
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Query GitHub advisories/discussions through the REST search API for public indicators
gh api search/issues -f q='grafana/alloy v1.7.1 vulnerability OR advisory OR CVE' --jq '.total_count, .items[] | {title, html_url, created_at}'Repository: AET-DevOps26/team-devsecops
Length of output: 296
Bump Alloy to the current stable release. grafana/alloy:v1.7.1 is far behind the current stable v1.17.1, so update this image to pick up the latest fixes and security patches.
🤖 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 `@infra/k8s/monitoring/alloy.yaml` at line 137, Update the Grafana Alloy
container image under the Kubernetes monitoring configuration from
grafana/alloy:v1.7.1 to the current stable grafana/alloy:v1.17.1.
| containers: | ||
| - name: loki | ||
| image: grafana/loki:3.4.2 | ||
| args: | ||
| - -config.file=/etc/loki/loki.yaml | ||
| ports: | ||
| - containerPort: 3100 | ||
| name: http | ||
| readinessProbe: | ||
| httpGet: | ||
| path: /ready | ||
| port: http | ||
| initialDelaySeconds: 30 | ||
| periodSeconds: 10 | ||
| volumeMounts: | ||
| - name: config | ||
| mountPath: /etc/loki | ||
| - name: data | ||
| mountPath: /loki | ||
| resources: | ||
| requests: | ||
| cpu: 50m | ||
| memory: 128Mi | ||
| limits: | ||
| cpu: 500m | ||
| memory: 384Mi |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
Add container-level security context to the Loki container.
The Loki container has no securityContext at the container level. It runs as root by default, allows privilege escalation, and has a writable root filesystem. Add runAsNonRoot, runAsUser, readOnlyRootFilesystem, and allowPrivilegeEscalation: false to harden the deployment.
🔒️ Proposed security hardening
containers:
- name: loki
image: grafana/loki:3.4.2
+ securityContext:
+ runAsNonRoot: true
+ runAsUser: 10001
+ readOnlyRootFilesystem: true
+ allowPrivilegeEscalation: false
args:
- -config.file=/etc/loki/loki.yaml📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| containers: | |
| - name: loki | |
| image: grafana/loki:3.4.2 | |
| args: | |
| - -config.file=/etc/loki/loki.yaml | |
| ports: | |
| - containerPort: 3100 | |
| name: http | |
| readinessProbe: | |
| httpGet: | |
| path: /ready | |
| port: http | |
| initialDelaySeconds: 30 | |
| periodSeconds: 10 | |
| volumeMounts: | |
| - name: config | |
| mountPath: /etc/loki | |
| - name: data | |
| mountPath: /loki | |
| resources: | |
| requests: | |
| cpu: 50m | |
| memory: 128Mi | |
| limits: | |
| cpu: 500m | |
| memory: 384Mi | |
| containers: | |
| - name: loki | |
| image: grafana/loki:3.4.2 | |
| securityContext: | |
| runAsNonRoot: true | |
| runAsUser: 10001 | |
| readOnlyRootFilesystem: true | |
| allowPrivilegeEscalation: false | |
| args: | |
| - -config.file=/etc/loki/loki.yaml | |
| ports: | |
| - containerPort: 3100 | |
| name: http | |
| readinessProbe: | |
| httpGet: | |
| path: /ready | |
| port: http | |
| initialDelaySeconds: 30 | |
| periodSeconds: 10 | |
| volumeMounts: | |
| - name: config | |
| mountPath: /etc/loki | |
| - name: data | |
| mountPath: /loki | |
| resources: | |
| requests: | |
| cpu: 50m | |
| memory: 128Mi | |
| limits: | |
| cpu: 500m | |
| memory: 384Mi |
🤖 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 `@infra/k8s/monitoring/loki.yaml` around lines 74 - 99, Add a container-level
securityContext to the loki container definition, setting runAsNonRoot to true,
runAsUser to a non-root UID, readOnlyRootFilesystem to true, and
allowPrivilegeEscalation to false. Keep the existing volume mounts for writable
paths.
Source: Linters/SAST tools
| fsGroup: 10001 | ||
| containers: | ||
| - name: loki | ||
| image: grafana/loki:3.4.2 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check for Loki security advisories and latest version
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: DOCKER, package: "grafana/loki") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'Repository: AET-DevOps26/team-devsecops
Length of output: 645
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Inspect the Loki manifest around the referenced line and check for the pinned image usage.
sed -n '60,90p' infra/k8s/monitoring/loki.yamlRepository: AET-DevOps26/team-devsecops
Length of output: 860
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Query the Grafana Loki repo for the latest release tags and confirm whether 3.4.2 is still current.
gh api repos/grafana/loki/releases --paginate --jq '.[].tag_name' | sed -n '1,20p'Repository: AET-DevOps26/team-devsecops
Length of output: 355
🌐 Web query:
Grafana Loki latest stable release and known security advisories for grafana/loki 3.4.2
💡 Result:
As of July 10, 2026, the latest stable release of Grafana Loki is v3.7.3, released on June 24, 2026 [1]. Regarding Grafana Loki version 3.4.2, it is affected by a known security vulnerability: CVE-2026-21726 (also tracked as GHSA-497x-rrr9-68jp): This is a Path Traversal vulnerability in the Ruler API endpoint (/loki/api/v1/rules/{namespace}) [2][3]. The vulnerability allows an attacker to bypass previous fixes for CVE-2021-36156 by using double encoding to read files [2][4]. This vulnerability affects versions of Loki prior to 3.6.4 [5][4][3]. Since 3.4.2 is older than 3.6.4, it is vulnerable [5][2]. Users are advised to upgrade to a patched version (v3.6.4 or later) to mitigate this issue [2].
Citations:
- 1: https://github.com/grafana/loki/releases/tag/v3.7.3
- 2: https://grafana.com/security/security-advisories/cve-2026-21726/
- 3: https://pkg.go.dev/vuln/GO-2026-5115
- 4: https://osv.dev/vulnerability/CVE-2026-21726
- 5: https://repology.org/project/grafana-loki/cves?version=3.4.2
Upgrade the Loki image pin. infra/k8s/monitoring/loki.yaml:76 still uses grafana/loki:3.4.2, which is behind the current stable release and affected by CVE-2026-21726; bump to at least v3.6.4 (preferably the latest stable).
🤖 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 `@infra/k8s/monitoring/loki.yaml` at line 76, The Loki container image is
pinned to outdated version 3.4.2 and must be upgraded. Update the image
reference in the Loki deployment to grafana/loki:v3.6.4 or a newer stable
release, preserving the existing image configuration.
471f1a9 to
3600367
Compare
imol-ai
force-pushed
the
feat/grafana-logs
branch
from
3600367 to
6c88c47
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
infra/k8s/monitoring/grafana-alerting.yaml (1)
47-92: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low valueError rate alert expression lacks zero-traffic safeguard present in dashboard.
The alert expression on line 61 divides by
sum(rate(http_server_requests_seconds_count{job="spring-api"}[5m]))without a fallback. When there's no traffic, this produces an empty/no-data result, whichnoDataState: OKhandles correctly. However, the dashboard version of the same query (grafana-dashboards.yaml line 124) addsor on() vector(0)to the numerator for explicit handling. Consider aligning the alert expression for consistency and to avoid relying solely onnoDataStatefor the no-data path.♻️ Optional: align alert expression with dashboard version
- expr: '100 * sum(rate(http_server_requests_seconds_count{job="spring-api",outcome="SERVER_ERROR"}[5m])) / sum(rate(http_server_requests_seconds_count{job="spring-api"}[5m]))' + expr: '100 * (sum(rate(http_server_requests_seconds_count{job="spring-api",outcome="SERVER_ERROR"}[5m])) or on() vector(0)) / sum(rate(http_server_requests_seconds_count{job="spring-api"}[5m]))'🤖 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 `@infra/k8s/monitoring/grafana-alerting.yaml` around lines 47 - 92, Update the Prometheus expression in the spring-api-high-error-rate alert’s refId A model to match the dashboard’s zero-traffic handling by adding `or on() vector(0)` to the numerator before division. Preserve the existing 5xx rate calculation and threshold configuration while ensuring the no-traffic result explicitly evaluates to zero.
🤖 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.
Nitpick comments:
In `@infra/k8s/monitoring/grafana-alerting.yaml`:
- Around line 47-92: Update the Prometheus expression in the
spring-api-high-error-rate alert’s refId A model to match the dashboard’s
zero-traffic handling by adding `or on() vector(0)` to the numerator before
division. Preserve the existing 5xx rate calculation and threshold configuration
while ensuring the no-traffic result explicitly evaluates to zero.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 65cc62bc-a0eb-45ac-8f4a-60a97d73a8bc
📒 Files selected for processing (5)
.github/workflows/deploy-k8s.ymlinfra/k8s/monitoring/grafana-alerting.yamlinfra/k8s/monitoring/grafana-dashboards.yamlinfra/k8s/monitoring/grafana.yamlservices/spring-api/src/main/resources/application.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- infra/k8s/monitoring/grafana.yaml
imol-ai
force-pushed
the
feat/grafana-logs
branch
from
6c88c47 to
c76c5d1
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (1)
infra/k8s/monitoring/grafana.yaml (1)
56-58: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winAdd container-level
securityContext.The pod sets
fsGroup: 472but the container lacksrunAsNonRoot,runAsUser, andallowPrivilegeEscalation: false. Adding these hardens the Grafana pod against privilege escalation and ensures it runs as non-root even if the image default changes.🔒️ Proposed fix
containers: - name: grafana image: grafana/grafana:11.6.16 + securityContext: + runAsNonRoot: true + runAsUser: 472 + allowPrivilegeEscalation: false env:🤖 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 `@infra/k8s/monitoring/grafana.yaml` around lines 56 - 58, Add a container-level securityContext to the Grafana container, setting runAsNonRoot: true, runAsUser: 472, and allowPrivilegeEscalation: false; retain the existing pod-level fsGroup setting.
🤖 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.
Nitpick comments:
In `@infra/k8s/monitoring/grafana.yaml`:
- Around line 56-58: Add a container-level securityContext to the Grafana
container, setting runAsNonRoot: true, runAsUser: 472, and
allowPrivilegeEscalation: false; retain the existing pod-level fsGroup setting.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2b5ea544-2a88-4977-87e6-a18982884603
📒 Files selected for processing (5)
.github/workflows/deploy-k8s.ymlinfra/k8s/monitoring/grafana-alerting.yamlinfra/k8s/monitoring/grafana-dashboards.yamlinfra/k8s/monitoring/grafana.yamlservices/spring-api/src/main/resources/application.yaml
🚧 Files skipped from review as they are similar to previous changes (4)
- services/spring-api/src/main/resources/application.yaml
- .github/workflows/deploy-k8s.yml
- infra/k8s/monitoring/grafana-dashboards.yaml
- infra/k8s/monitoring/grafana-alerting.yaml
imol-ai
force-pushed
the
feat/grafana-logs
branch
from
c76c5d1 to
e3cd18c
Compare
1 participant
Summary
Adds collection of logs to grafana, some dashboards, and alerting.
Closes #120
Type of change
API changes
api/openapi.yamlupdated andapi/scripts/gen-all.shre-runDefinition of Done
Summary by CodeRabbit