Description
I'm submitting a ...
- bug report
- new feature / enhancement request
- improvement request (usability, performance, tech debt, etc.)
- other
Traffic Control components affected ...
- CDN in a Box
- Documentation
- Grove
- Traffic Control Client
- Traffic Monitor
- Traffic Ops
- Traffic Ops ORT
- Traffic Portal
- Traffic Router
- Traffic Stats
- Traffic Vault
- unknown
Current behavior:
Currently there is a single anonymous blocking policy per CDN similar to how there is one CZF per CDN. This anonymous blocking policy controls which subsections of anonymous blocking are enforced, a redirection url, and IPv4/6 whitelists. This means that across an entire CDN there is one whitelist for every delivery service & tenant. So to add a whitelist entry for one delivery service also grants a bypass for all delivery services. This also limits every delivery service to a single redirect URL.
Expected / new behavior:
I'd like to see new database tables made to define the same policy concept at a per delivery service level. I'd also like to see a new non-enforcing mode added to aid in evaluating impacts to existing delivery services prior to switching on an enforcing state. This would also help assess needed whitelist entries or subsections that should be left as non-enforcing. This should generate success to the client like normal but in the TR log provide clues about if enforcing the policy would have denied the client.
Minimal reproduction of the problem with instructions:
Anything else:
We somewhat have this with how regional geo-blocking was implemented with multi-ds support, but it relies on json blobs to match up with delivery service IDs. This leads to easy missconfiguration and cruft accumulation as delivery services are removed. Another model to consider is SELinux. It has these ideas of policies in missing/permissive/enforcing states.