Openshift集群中对Kaniko作业的权限被拒绝

Question

我试图通过我的k8s运算符在openshift 3.11集群上进行部署。 kaniko作业启动时，出现以下错误。

Error: error resolving dockerfile path: copying dockerfile: open /kaniko/Dockerfile: 
permission denied

Answer 1

将securityContext: runAsUser: 0添加到pod规范中，以root身份运行它。

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0

Answer 2

Kaniko作为Build container images in Kubernetes and Google Container Builder without privileges的工具被引入。

我们很高兴推出kaniko，这是一个开放源代码工具，即使没有特权root访问，该工具也可以从Dockerfile构建容器映像。使用kaniko，我们都可以从Dockerfile构建映像并将其推送到注册表。由于不需要任何特殊特权或权限，因此您可以在标准的Kubernetes集群Google Kubernetes Engine或无法访问特权或Docker守护程序的任何环境中运行kaniko。

您遇到的问题已在GoogleContainerTools/kaniko GitHub问题中提到。

在1月11日，此问题被标记为Won't Fix，因此唯一的方法是使用securityContext: runAsUser: 0以root身份运行Kaniko。

这是不安全的，Kurt Madel在他的博客Securely Building Container Images on Kubernetes中提到：

以root运行是一种攻击媒介，许多人认为这是不可接受的安全漏洞-但是使用Pod安全策略将减少作为K8s Pod一部分运行的Kaniko容器的攻击面，并提供更大的安全性。比我们已经放弃的基于Docker的方法更安全。

他还解释了如何使用Kaniko the Easy Way

Jenkins X允许您enable Kaniko as the default way to build and push container images执行所有Jenkins X CD作业，并且将自动配置为推送到安装Jenkins X的云的默认容器注册表，并自动为您设置Kaniko缓存-生成快速，安全的容器映像，并将其推送到默认的Jenkins X容器注册表中。

重要提示：Jenkins X不具有this GitHub issue跟踪的OOTB对Pod安全策略的支持。在我的下一篇文章中，我们将介绍如何将Pod安全策略与Jenkins X结合使用-不仅限于Kaniko，因为一旦启用Pod安全策略，每个K8 Role / ClusterRole都必须具有Pod安全性与之相关的政策。

Kan子的缺点

• 需要以ROOT的身份运行Kaniko容器以执行大多数容器构建
• 不能与所有Dockerfiles一起使用，但会不断改进
• 设置比旧的docker build稍微复杂些