Include system policies in Gateway Builder #677
Conversation
WalkthroughThis PR refactors the gateway configuration and build pipeline by introducing rate-limiting policies, expanding analytics capabilities with publishers and Access Log Service configurations, reorganizing the policy manifest, and upgrading the API platform SDK dependency across all policy modules from v0.3.0 to v0.3.1. It also updates Docker Compose and build tooling to include system policies. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~30 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📜 Recent review detailsConfiguration used: Organization UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
✏️ Tip: You can disable this entire section by setting 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
🤖 Fix all issues with AI agents
In `@gateway/docker-compose.yaml`:
- Around line 186-187: The Grafana service currently uses the floating tag
"grafana/grafana:latest"; change the image reference for the grafana service to
the pinned version "grafana/grafana:12.2.0" to ensure reproducible builds and
consistent behavior across deployments—update the image string in the grafana
service block accordingly.
🧹 Nitpick comments (1)
gateway/configs/config.yaml (1)
343-355: Consider using environment variable syntax for sensitive configuration.The
application_iduses a raw placeholder<MOESIF_APPLICATION_ID>. For consistency with other configurations in this file (e.g.,GATEWAY_REGISTRATION_TOKENin docker-compose), consider using environment variable substitution or documenting how this should be overridden.
📜 Review details
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
gateway/configs/config.yamlgateway/docker-compose.yamlgateway/examples/weather-api.yamlgateway/policies/policy-manifest-lock.yaml
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-12-18T08:49:15.812Z
Learnt from: RakhithaRR
Repo: wso2/api-platform PR: 504
File: gateway/policies/mcp-auth/v0.1.0/policy-definition.yaml:118-191
Timestamp: 2025-12-18T08:49:15.812Z
Learning: The policy engine in the gateway validates configuration paths (e.g., `${config.policy_configurations.jwtauth_v010.*}`) in a case-insensitive manner, so references using lowercase (jwtauth_v010) will correctly match configuration keys using mixed case (JWTAuth_v010) in the Helm values or config files.
Applied to files:
gateway/configs/config.yaml
📚 Learning: 2025-12-12T04:05:38.530Z
Learnt from: Thenujan-Nagaratnam
Repo: wso2/api-platform PR: 385
File: gateway/policies/url-guardrail/v0.1.0/urlguardrail.go:261-281
Timestamp: 2025-12-12T04:05:38.530Z
Learning: In the api-platform repository, when adding new guardrail policies, security enhancements that are not present in existing/old policies are deferred to future versions to maintain consistency across policy implementations.
Applied to files:
gateway/policies/policy-manifest-lock.yaml
📚 Learning: 2025-12-18T08:49:08.028Z
Learnt from: RakhithaRR
Repo: wso2/api-platform PR: 504
File: gateway/policies/mcp-auth/v0.1.0/policy-definition.yaml:118-191
Timestamp: 2025-12-18T08:49:08.028Z
Learning: Ensure the policy engine resolves configuration paths in a case-insensitive manner when matching keys (e.g., jwtauth_v010 should match JWTAuth_v010 regardless of case). In reviews, look for references to path resolution logic and verify it normalizes keys (e.g., to lower or upper case) before comparison. Add tests to cover mixed-case Helm values and config keys and document this behavior in the policy engine's docs.
Applied to files:
gateway/policies/policy-manifest-lock.yaml
🔇 Additional comments (5)
gateway/examples/weather-api.yaml (1)
60-65: LGTM!The operation-level rate-limiting policy is correctly configured with sensible defaults (5 requests per minute). The policy name
basic-ratelimitand versionv0.1.0align with the policy manifest lock file.gateway/configs/config.yaml (2)
318-337: LGTM!The rate-limiting policy configuration is well-structured with sensible defaults: fixed-window algorithm for simplicity, in-memory backend suitable for single-instance deployments, and appropriate header controls for standard rate-limit response headers.
384-389: Verifymax_message_sizeis intentionally set to ~1GB.The value
1000000000bytes (~1GB) is quite large for gRPC message size. Ensure this aligns with expected access log batch sizes and won't cause memory pressure under high load. Typical defaults are in the 4-16MB range.gateway/docker-compose.yaml (1)
47-61: LGTM!The xDS server configuration correctly points to
gateway-controller:18001, matching the port exposed in the gateway-controller service (line 28). This enables dynamic policy configuration updates via xDS.gateway/policies/policy-manifest-lock.yaml (1)
3-75: LGTM!The policy manifest lock file is well-organized with 24 policies listed alphabetically. All entries maintain a consistent structure (name, version, filePath), use the standard
v0.1.0versioning, and all referenced policy directories exist in the repository.
✏️ Tip: You can disable this entire section by setting review_details to false in your review settings.
| grafana: | ||
| image: "" | ||
| container_name: grafana | ||
| image: "grafana/grafana:latest" |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat -n gateway/docker-compose.yaml | grep -A 2 -B 2 "grafana"Repository: wso2/api-platform
Length of output: 921
🏁 Script executed:
cat -n gateway/docker-compose.yaml | grep -E "image:" | head -20Repository: wso2/api-platform
Length of output: 717
🌐 Web query:
latest stable version of Grafana 2025 2026
💡 Result:
As of Jan 14, 2026 the latest stable Grafana release is Grafana 12.2.0 (released Sept 23, 2025). [1][2]
Sources:
- Grafana download page listing 12.2.0. [1]
- Grafana 12 release blog and security patch notes. [2]
Pin the Grafana image version for reproducibility.
Using the :latest tag can lead to non-reproducible builds and unexpected behavior when the upstream image changes. Other services in this file use pinned versions (e.g., prom/prometheus:v3.3.1, opensearchproject/opensearch:3.4.0). Update to the current stable version 12.2.0 instead of :latest.
📦 Suggested fix
grafana:
- image: "grafana/grafana:latest"
+ image: "grafana/grafana:12.2.0"📝 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.
| grafana: | |
| image: "" | |
| container_name: grafana | |
| image: "grafana/grafana:latest" | |
| grafana: | |
| image: "grafana/grafana:12.2.0" |
🤖 Prompt for AI Agents
In `@gateway/docker-compose.yaml` around lines 186 - 187, The Grafana service
currently uses the floating tag "grafana/grafana:latest"; change the image
reference for the grafana service to the pinned version "grafana/grafana:12.2.0"
to ensure reproducible builds and consistent behavior across deployments—update
the image string in the grafana service block accordingly.
renuka-fernando
changed the title
3 participants
Purpose
Summary by CodeRabbit
Release Notes
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.