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
Certs can be assigned to the NLB instead via ACM, and remove the burden of setting --cacert on the client side (possible today, but not sure if can be supported)
Because this retains TCP Source IP, etcd logs actual IPs
Cons
Pricing is significantly different, might need to be re-evaluated.
Thanks for the detailed suggestion. NLBs are good, better than ELBs for the use-case obviously for some of the reasons you stated above, but also a few others regarding flow reliability. However, after only looking a few seconds at the articles, I do not see any motion of client certificate authentication. Is that only straight-up TLS termination only?
There is also the debate of having unencrypted traffic flowing between the NLB hosts and your etcd hosts, which may be a security concern for several companies out there.
I do not see any mention of client certificate authentication
Good catch. I saw some other comments asking for this as well, but I guess this will have to be tested.
There is also the debate of having unencrypted traffic flowing between the NLB hosts and your etcd hosts
No plans of doing that. Want to setup TLS through and through. So the etcd-server cert is self-signed, and marked as origin cert on the NLB (I think it supports this, but need to check).
Will check on support for both of these and report back.
Creating this issue to start a discussion.
Pros
--cacert
on the client side (possible today, but not sure if can be supported)Cons
Reference:
The text was updated successfully, but these errors were encountered: