I have a security requirement to include in my event logs the machine name / hostname on which an instance of my application is running. Presumably this is so that a security auditor who is trying to trace through a breach can determine, e.g., if the breach is related to one specific compromised machine. This also assumes that all of the logs are being collected centrally in a SIEM or something like one, so you need to know where each event came from.
This was always easy in the past on monolithic applications. However, now I'm working on a Kubernetes-based cloud app with various micro-services. /etc/hostname shows a bs pod name, as each pod has it's own filesystem. The "hostname" command doesn't appear to be installed; even if it were, I have no faith that it wouldn't just parrot the information in /etc/hostname. I need to get the name of the actual machine on which the pod is running from inside the code that is running in the pod (before somebody says "why don't you use kubectl"?); I am happy to accept the name of the VM on which the Kubernetes node containing the instance of the pod is running, assuming that getting all the way back to the hypervisor machine name is a bridge too far.
Is there a way that an application (e.g. a C# dot net web app running using Kestrel as the web server) can reach out of the container and pod to get this information? Or a reasonable way that I can get the scheduler to write over a config map entry immediately before it spins the pod up so the app can read it from there (yes, we are using Helm, but this is information only the scheduler knows at the time the pod is being instantiated)? Or do I have to have an argument with the Cyber folks about how their requirement is impossible to achieve?
Perhaps the easiest way to do this is to use Kubernetes Downward API. You can expose node name via environment variable defined in Pod spec:
env:
- name: MY_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName