You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 12, 2023. It is now read-only.
Could we have another policy, similar to https://github.com/cruise-automation/k-rail#unique-ingress-host, which could prevent deployment of Istio VirtualServices with duplicate names? The policy would serve the same purpose - preventing the accidental (or deliberate) interception of traffic to one service simply by creating a matching virtualservice in another namespace.
I'd be happy to take a crack at duplicating policies/ingress/unique_ingress_host.go myself, but might need help to add a check to ensure that the necessary CRD to list VirtualServices even exists in the cluster.
Here's an example virtualservice record - the record we care about is spec.hosts
I don't think we need any special consideration for ensuring the CRD is present - just handling the error and ensuring the request continues to the apiserver so the user gets that feedback should be enough.
👋 The k-rail project has been deprecated and is no longer under active development. We recommend taking a look at OPA Gatekeeper to see if it might meet your needs going forward.
Thanks for your contribution(s) to the project!
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hey guys,
Could we have another policy, similar to https://github.com/cruise-automation/k-rail#unique-ingress-host, which could prevent deployment of Istio VirtualServices with duplicate names? The policy would serve the same purpose - preventing the accidental (or deliberate) interception of traffic to one service simply by creating a matching virtualservice in another namespace.
I'd be happy to take a crack at duplicating
policies/ingress/unique_ingress_host.go
myself, but might need help to add a check to ensure that the necessary CRD to list VirtualServices even exists in the cluster.Here's an example virtualservice record - the record we care about is
spec.hosts
Thanks!
D
The text was updated successfully, but these errors were encountered: