Allow/Deny Filtering for Maven Virtual Registry
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Description:
As part of expanding Virtual Registry capabilities, we want to support allow/deny filtering when configuring upstreams for Maven. This will give users more granular control over which packages can be consumed from external sources.
These filters will:
- Provide granular control over which packages can be consumed from external sources.
- Create flexible rule-based filtering for package inclusion/exclusion
- Support pattern matching for package names and scopes
- Implement version-specific filtering capabilities
- Provide audit logs for blocked package requests
The implementation is expected to happen during upstream creation.
User Story:
As a platform engineer, I want to define allow/deny rules when adding an upstream to a Maven Virtual Registry, so that only approved packages are made available to the developers.
Acceptance Criteria:
Core Filtering Functionality
- Given I am creating/editing a Maven Virtual Registry upstream, when I configure allow/deny filters, then I can define multiple pattern-based rules
- Given an allow list is configured, when a package request doesn't match any allow pattern, then the request is rejected with a clear error message
- Given a deny list is configured, when a package request matches any deny pattern, then the request is rejected with a clear error message
- Given both allow and deny lists are configured, when a package matches both lists, then the deny rule takes precedence and the request is rejected
Pattern Flexibility:
- Given I select "Simple" pattern mode, when I use wildcards, then the system translates them to appropriate regex internally
- Given I select "Advanced" pattern mode, when I enter regex patterns, then the system validates regex syntax before saving
- Given I create a regex pattern, when I use the built-in pattern tester, then I can validate matches against sample package coordinates
Pattern Templates:
- Given I'm configuring filters, when I access pattern templates, then I can select from common scenarios (block snapshots, allow version ranges, etc.)
User Interface
- Given I am on the upstream configuration page, when I add filter rules, then I can add/remove multiple allow and deny patterns with intuitive form controls
- Given I enter an invalid pattern format, when I attempt to save, then I receive clear validation feedback
- Given I have configured filters, when I view the upstream configuration, then I can see a clear summary of active allow/deny rules
Audit and Monitoring
- Given a package request is blocked by filters, when the rejection occurs, then an audit log entry is created with timestamp, requesting user, blocked package coordinates, and matching rule
- Given I have appropriate permissions, when I access audit logs, then I can filter and search blocked package requests by date range, user, or package pattern
Performance and Validation
- Given I configure filter patterns, when I save the configuration, then the system validates pattern syntax before applying
- Given that multiple filter rules are configured, when package requests are processed, then filtering operations complete within acceptable performance thresholds (suggest defining specific SLA)
Value:
- Security & Compliance: Prevent usage of unverified or deprecated packages by enforcing policy through filtering.
- Scalability: Makes managing large or complex registries easier with rule-based controls.
⚙️ Technical aspects
Maven package coordinates are 3 strings that uniquely identify a package within a Maven package registry:
- A
groupId. - A
artifactId. - A
version.
Regarding the allow and deny list, the logic should combine them:
- If an allow list is set. Any unmatched package request should be rejected.
- If a reject list is set. Any matched package request should be rejected.