如何查找您的应用程序正在哪个 Kubernetes 节点上运行（从应用程序内部）
我有一个安全要求，需要在事件日志中包含运行应用程序实例的计算机名称/主机名。据推测，这是为了让试图追踪漏洞的安全审计员可以确定该漏洞是否与一台特定的受感染机器有关。这还假设所有日志都在 SIEM 或类似的设备中集中收集，因此您需要知道每个事件的来源。
过去，这在单体应用程序中总是很容易。然而，现在我正在开发一个基于 Kubernetes 的具有各种微服务的云应用程序。 /etc/hostname 显示 bs pod 名称，因为每个 pod 都有自己的文件系统。 “hostname”命令似乎没有安装；即使是这样，我也不相信它不会只是鹦鹉学舌地重复 /etc/hostname 中的信息。我需要从 Pod 中运行的代码内部获取运行 Pod 的实际机器的名称（在有人说“你为什么不使用 kubectl”之前？）；我很高兴接受包含 pod 实例的 Kubernetes 节点正在其上运行的 VM 的名称，假设一直返回到虚拟机管理程序计算机名称是一个太远的桥梁。
有没有一种方法可以让应用程序（例如，使用 Kestrel 作为 Web 服务器运行的 C# dot net Web 应用程序）可以从容器和 Pod 中获取此信息？或者一种合理的方法，我可以让调度程序在旋转 Pod 之前立即写入配置映射条目，以便应用程序可以从那里读取它（是的，我们正在使用 Helm，但这是只有调度程序知道的信息） Pod 被实例化的时间）？或者我是否必须与网络人员争论他们的要求如何无法实现？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
也许最简单的方法是使用 Kubernetes 向下 API。您可以通过 Pod 规范中定义的环境变量公开节点名称：
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: