OpenShift Tekton流水线Kaniko构建镜像报operation not permitted错误

该报错由OpenShift集群默认的安全上下文约束（SCC）与Kaniko的构建逻辑冲突导致：Kaniko解压基础镜像层时，需要为镜像内的文件写入安全扩展属性（本次报错是为/usr/bin/ping写入security.capability权能属性），但OpenShift默认给工作负载Pod分配随机非root用户UID，且未授予CAP_SETFCAP、CAP_FOWNER等修改文件扩展属性所需的权能，直接触发操作拒绝，导致构建流程中断。

按优先级从高到低排列，优先选择对集群安全影响最小的方案：

方案1：为Kaniko任务配置最小必要权能（推荐，无安全风险） #

无需修改基础镜像、无需授予root权限，仅需给Kaniko运行时添加必要的权能即可解决属性写入权限问题。
在流水线的build-push-kaniko任务段添加podTemplate配置，覆盖默认安全上下文：

- name: build-push-kaniko
  runAfter: ["maven-build-war"]
  taskRef:
    name: kaniko
  # 新增以下Pod安全配置
  podTemplate:
    securityContext:
      runAsNonRoot: true
      capabilities:
        add:
          - SETFCAP
          - FOWNER
          - DAC_OVERRIDE
  workspaces:
    - name: source
      workspace: source-dir
    - name: aws-credentials
      workspace: aws-credentials            
  params:
    - name: IMAGE
      value: "$(params.ecr-registry)/$(params.ecr-repository):$(params.ecr-image-tag)"

如果集群SCC限制较严，需要提前给流水线使用的ServiceAccount绑定允许添加上述权能的自定义SCC，无需绑定特权SCC。

方案2：添加Kaniko启动参数跳过属性写入校验（次选，配置最简单） #

如果不方便调整集群SCC和安全上下文，可以直接给Kaniko传入官方提供的忽略属性错误参数，跳过扩展属性写入步骤，适配无特权运行场景。
在Kaniko任务的参数中添加--ignore-attribute-errors=true，如果所用的Kaniko Task支持EXTRA_ARGS入参，配置示例如下：

params:
  - name: IMAGE
    value: "$(params.ecr-registry)/$(params.ecr-repository):$(params.ecr-image-tag)"
  - name: EXTRA_ARGS
    value:
      - "--ignore-attribute-errors=true"

注意：如果所用的Kaniko Task没有EXTRA_ARGS入参，可以直接把该参数追加到任务的启动args列表中。该参数会跳过所有文件扩展属性（包括权能、自定义xattr）的写入，最终构建的镜像中/usr/bin/ping原本的cap_net_raw权限会丢失，Java业务应用不依赖ping等需要原始套接字的系统工具时，该方案无任何副作用。

方案3：使用root用户+特权SCC运行Kaniko（临时排障用，不推荐生产使用） #

如果前两个方案均不生效，可以给运行Kaniko任务的ServiceAccount绑定OpenShift的privileged SCC，以root用户运行Kaniko，可彻底解决权限问题，但不符合OpenShift安全最佳实践，存在容器逃逸风险，仅建议临时排障使用。
操作步骤：

1. 为流水线使用的ServiceAccount绑定特权SCC，执行命令：

   oc adm policy add-scc-to-user privileged -z <流水线运行所用的ServiceAccount名称> -n <流水线所在命名空间>
   

2. 在Kaniko任务的podTemplate中添加root用户运行配置：

   podTemplate:
     securityContext:
       runAsUser: 0
       runAsNonRoot: false
   

配置修改完成后重新运行流水线，观察Kaniko构建日志，解压基础镜像层时不会再出现security.capability写入报错，后续镜像构建、推送至ECR的流程可正常执行。

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