-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
daemon: Add --disable-sip-verification flag #18274
daemon: Add --disable-sip-verification flag #18274
Conversation
Commit 48354afbba80ebaa341ac77f6d6c3951bc28bbb9 does not contain "Signed-off-by". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
Commits 48354afbba80ebaa341ac77f6d6c3951bc28bbb9, 73c37466ab070b4affc2db87fb5c3f452c31545b do not contain "Signed-off-by". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
Commits 48354afbba80ebaa341ac77f6d6c3951bc28bbb9, 73c37466ab070b4affc2db87fb5c3f452c31545b, 40797cd72e4e5439315f5c03c3eb4a8ebc6d0f2d do not contain "Signed-off-by". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
Commits 48354afbba80ebaa341ac77f6d6c3951bc28bbb9, 73c37466ab070b4affc2db87fb5c3f452c31545b, 40797cd72e4e5439315f5c03c3eb4a8ebc6d0f2d, 751010b24fb96338d9d7a83622704e8c91b01876 do not contain "Signed-off-by". Please follow instructions provided in https://docs.cilium.io/en/stable/contributing/development/contributing_guide/#developer-s-certificate-of-origin |
751010b
to
861013c
Compare
Add flag to disable sip veification. This will allow to configure the datapath so it dose'nt drop packets due to invalid source ip in the datapath. This is helpful when routing IP payload from external ip networks through kubernets via ip tunnels. See cilium#16134 for more infomations. Signed-off-by: Michael Raskansky <michaelraskansky@gmail.com>
861013c
to
9c2ead1
Compare
/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that this will break chaining mode as-is, would be good to confirm whether or not that is the case and ensure that we mitigate such a problem before merging.
I've posted another couple of other minor nits, then one bigger security question as well.
if epTemplate.DatapathConfiguration == nil { | ||
epTemplate.DatapathConfiguration = &models.EndpointDatapathConfiguration{} | ||
} | ||
if option.Config.EnableEndpointRoutes { | ||
if epTemplate.DatapathConfiguration == nil { | ||
epTemplate.DatapathConfiguration = &models.EndpointDatapathConfiguration{} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned that this will break chaining mode, for reasons described in commit 8da8b88.
@@ -1045,7 +1048,6 @@ func (h *putEndpointIDLabels) Handle(params PatchEndpointIDLabelsParams) middlew | |||
func (d *Daemon) QueueEndpointBuild(ctx context.Context, epID uint64) (func(), error) { | |||
// Acquire build permit. This may block. | |||
err := d.buildEndpointSem.Acquire(ctx, 1) | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unrelated change, no need to drop this line.
@@ -2892,6 +2899,7 @@ func (c *DaemonConfig) Populate() { | |||
c.DisableCNPStatusUpdates = viper.GetBool(DisableCNPStatusUpdates) | |||
c.EnableICMPRules = viper.GetBool(EnableICMPRules) | |||
c.BypassIPAvailabilityUponRestore = viper.GetBool(BypassIPAvailabilityUponRestore) | |||
c.DisableSipVerification = viper.GetBool(DisableSipVerification) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder about the security implications of this and how to appropriately warn users.
This can allow IP spoofing across the network via pods created with this option. This can mean bypassing security policy if someone is able to send traffic to this pod and convince it to route that traffic with an in-cluster source IP towards an in-cluster destination.
At minimum, I would be inclined to hide this option and warn very loudly and angrily to anyone deploying the option that they are potentially compromising the security of their cluster by using this option. Arguably we could perhaps discuss a more comprehensive solution to this sort of problem and come up with better guardrails. I'd welcome proposals that outline potential security concerns and mitigations with this approach.
Obviously if the user just knows best and how to properly secure their network, then they presumably could just configure this option and whatever else they need in order to have this do what they want. I don't necessarily see a reason to get in their way for this (although I could also see an argument that maybe they should just maintain these changes out-of-tree). Mostly what I'd like to avoid is giving the impression that this is a standard supported option in Cilium that anyone can safely turn on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, Joe.
I understand your point, of course security should be a primary concern, I think as you suggested, the option should be hidden and if it is used, we can log an explicit warning regarding the potential security risk of running the cluster with this option set in the startup log and evaluate adding it in the cilium status command output.
The issue I am having with source IP verification, is that it blocks all traffic exiting the pod which has a different source IP than the internal cluster IP assigned to the pod by the cluster, whether it is traffic forwarded via the pod or traffic which originated from the pod (I.E using a virtual IP). This can be problematic when running NFV applications within pods, for instance a pod can act as a VPN gateway which handles external user traffic and then forwards the traffic either internally (within the cluster) or to an external service.
A more comprehensive solution which can be evaluated is to associate external networks (not cluster-internal) with specific endpoints, for instance, endpoint X can be configured to be associated with external networks X.X.X.X/24 and Y.Y.Y.Y/32, any traffic exiting the endpoint from these networks will be allowed, (not dropped by source IP validation mechanism).
Co-authored-by: Joe Stringer <joestringernz@gmail.com>
This pull request has been automatically marked as stale because it |
This pull request has not seen any activity since it was marked stale. |
Like in similar requests, we have applications that require to be able to send packets from IP addresses different than the ones assigned by Cilium, (e.g. NetFlow data replicated by samplicator-> https://github.com/sleinen/samplicator).
|
Add flag to disable sip verification.
This will allow to configure the datapath so it doesn't drop packets due to invalid source IP in the datapath.
This is helpful when routing IP payload from external ip networks through kubernets via ip tunnels. See #16134 for more information.
Signed-off-by: Michael Raskansky michaelraskansky@gmail.com