Change:
-gcflags "${gogcflags:-}" -asmflags "${goasmflags:-}" -ldflags "${goldflags:-}" <ins> -buildmode pie </ins> -tags "${gotags:-}" ) kube::golang::build_some_binaries "${nonstatics[@]}"

Discussion:
Currently is dynamically linked but is not built as a position independent executable. It would be great if it could be built with Go’s flag to enable ASLR. I’m not a security expert, and I’m not familiar with those concepts, but it seems that ASLR is a pretty common (and recommended) security mechanism. If I understand correctly, statically linked binaries (e.g. all the Kubernetes binaries except ) do not require/support PIE so this would only apply to . There was an attempt at using Go’s in but it seems that it was abandoned due to an incompatibility issue with Windows.
/sig release
cc
ASLR stands for Address Space Layout Randomization ref:
conditionally building only Linux binaries in PIE for ASLR seems acceptable. the problem is k8s is using a bash library for building which is not very flexible. also not clear how this would work for bazel builds.
I know at least some distributions which build go binaries per default with . do you see any reason to not turn it on for Linux per default?
i think it should be turned on. my comment was that our build infra is a bit entangled at places. /priority backlog the label seems appropriate.
Whoa! timely - https://go- also https://go-
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
I will work on this issue.
/sig security
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at .

/lifecycle stale
/remove-lifecycle stale
there are outstanding questions about this PTAL, I can lend some pointers to the build but I'd like more input on if this is desirable / worthwhile. Some notes: buildmode=pie does not seem to be supported for all platforms even on linux, which seems problematic given that we compile for many platforms. Custom builds can of course set this without the Kubernetes project choosing to do so, see .
IMO, there's value in building as PIE on the platforms where that is possible, but this is a low priority / nice-to-have. shows one way that building a PIE to enable ASLR can make attacks harder even though Go is memory-safe. It could also be a mitigation against a hypothetical memory-unsafety bug in the Go runtime.
not sure if it moves the discussion forward but ASLR is one mechanism to address NIST 800-53 control requirements for memory integrity/protection (ie SI-16). CIS mapped this in one of their . Note that is an older mapping and rev 5 is coming soon which keep this in as a requirement. I'm an expert enough not to call myself an expert in anything but I can argue it both ways but ultimately it comes down to this - we do a lot in all layers of a system for security and sometimes those help compliance, similarly we do a lot in all layers of a system for compliance that in no way help security but pay the bills. You can judge which is the greater good (or evil).
ROP mitigation is probably the most valuable aspect of this since Kubelet is always running in memory. Its binary may be a rich source of gadgets, of which their offsets in the binary need to be well known to an attacker.
cc to take a look
Started to follow-up on this in