当附加到容器时,在附加会话期间执行的所有命令和输出都将通过可抓取的pods/log可见。
复现步骤:
运行一个pod并使用以下命令直接附加到其shell:
kubectl run -it my-pod —image=busybox — sh
一旦pod启动并附加,终端中输入的任何内容不仅在Kubernetes控制台上(例如在Openshift pod日志选项卡中)可见,而且还由像fluentbit这样的日志提取器抓取,并转发到ELK/EFK等。
许多SRE、基础设施工程师和故障排除人员运行此类pod以进行故障排除和发现问题,并且在故障排除过程中经常使用凭据和其他敏感信息。
例如:
curl -u username:mypass http://example.com/
将在控制台上记录用户名和密码,并最终记录到日志中
注意:当进入容器时,该会话永远不会被记录
建议:
向用户添加警告,提醒他们注意all commands and output executed when attached to a container will be visible via pods/log
,以帮助那些可能不期望这种行为的用户
最初由@yosuf报告
6条答案
按热度按时间m528fe3b1#
4uqofj5v2#
我认为也是
/sig security
ewm0tg9j3#
我们需要在kubectl attach时发出警告,对吗?
例如:
hl0ma9xz4#
我们需要在kubectl attach时发出警告,对吗?
就像这样:
是的,这是一个很好的开始。
xv8emn3q5#
所以我们只需要在kubectl attach时发出警告,对吗?
就像这样:
是的,这是一个很好的开始。
在提交任何PR或更改之前,我们应该在SIG Auth/node等会议上讨论这个问题。
kmpatx3s6#
大家好,关于这个问题,我们可能需要在文档和/或警告中注明
kubectl debug pod
。我猜调试场景中人们有很大可能会在shell中放入凭据或敏感数据,而且由于调试容器(默认情况下)不共享主容器的进程/PID命名空间,从我看到的日志中可以看出,shell输出被捕获。编辑 :经过更多测试,似乎即使启用了进程命名空间共享,也会捕获临时容器的数据...