GitLab CI中aquasec/tfsec的entrypoint作用及Docker运行报错原因

1. GitLab CI配置中entrypoint命令的作用 #

默认情况下，aquasec/tfsec镜像的entrypoint是tfsec程序本身。在GitLab CI配置里把entrypoint改成["/bin/sh", "-c"]，核心目的是让容器以shell作为启动入口，而非直接启动tfsec。

这样做的好处是，GitLab CI后续的脚本（哪怕配置里没显式写script字段，流水线也会默认执行相关操作）可以通过shell来解析执行——比如先切换到项目目录，再调用tfsec进行扫描，或者执行其他预处理命令。如果不改entrypoint，GitLab CI的脚本内容会被直接当作参数传给tfsec，大概率不符合预期。另外配置里的allow_failure: true是让这个扫描任务就算失败，也不会中断整个流水线的运行。

2. 本地docker run命令失败的原因 #

你直接执行docker run --rm -it aquasec/tfsec /bin/sh时，是在使用镜像默认的entrypoint（也就是tfsec），此时/bin/sh会被当成tfsec的参数——tfsec会把这个路径当成要扫描的目标目录，但/bin/sh是个可执行文件而非目录，所以就会抛出Error: provided path is not a dir的错误。

而GitLab CI里已经覆盖了entrypoint为shell，容器启动后会先进入shell环境，再执行扫描相关的命令（比如GitLab CI会自动挂载你的项目代码目录，然后在shell里调用tfsec扫描该目录），所以能正常运行。

如果想本地正常进入该镜像的shell，需要显式覆盖entrypoint，命令应该是：

docker run --rm -it --entrypoint /bin/sh aquasec/tfsec

内容的提问来源于stack exchange，提问作者Rad4