-
Task
-
Resolution: Done
-
Major
-
None
-
False
-
False
-
*USER STORY:*
As a SPLAT Engineer], I want to share the knowledge to replace the API's (NLB's) target group to use target strategy as Instance, instead IP (default IPI), so kube-apiserver can track the source IPs (client IPs) from audit logs, so OpenShift engineers (PnT, CEE, etc) can be benefit with that runbook when troubleshoot issues, ask questions from Customers, etc.
*DESCRIPTION:*
The motivation of this runbook is to review the current steps to replace the target groups (public and private) from kube-apiserver’s NLB to a strategy of targetId (which uses instance IDs instead of targetIp (which use instance IPs). Original conversation started on slack.
Currently the API server is using targets as “IP” (instance IP) with ProxyV2 disabled on NLB (Network Load Balancer) in AWS deployment on listeners from both balancers (private and public). Using that strategy, the Client IP (source IP) will be the IP’s from the balancer's node, instead of the real source.
The current kube-apiserver code does not support ProxyV2 headers (TCP), only HTTP headers (see this to parse X-Forward-For and X-Real-Ip, in general used by ALB) so the remoteIP will be the balancer’s node. It may need an additional development effort to parser and get the (real) source IP for TCP data when enabling ProxyV2 (not covered in this document, sample app is a target of this card).
*Required:*
- runbook/document with steps to replace the target groups
*ACCEPTANCE CRITERIA:*
- share the steps on AWS to replace the API’s target groups to Instance ID
- understand the impact of this change on kube-apiserver
- share insights to use this in UPI deployments, or troubleshooting IPI clusters
*ENGINEERING DETAILS:*
- relates to
-
SPLAT-297 [aws][nlb] research the impacts in existing Go apps when ProxyV2 is Enabled and how to read Client's IP from proxy's payload
- Closed