AWS EKS部署.NET6应用报Permission denied如何解决

两个报错均由安全加固配置的细节缺失导致，和Kestrel端口监听逻辑本身无关：

1. 持续抛出的System.Net.Sockets.SocketException (13): Permission denied：开启readOnlyRootFilesystem: true后，没有为运行时需要写入的临时路径挂载可写卷。Kestrel绑定端口时会在临时目录创建socket元数据文件，只读文件系统下文件创建失败就会抛出权限错误，和监听端口是否低于1024无关。
2. 偶发的Failed to create CoreCLR, HRESULT: 0x80004005：存在两个触发点，一是使用了已废弃的COMPlus_EnableDiagnostics环境变量，.NET 6不再识别该前缀的配置，运行时默认会尝试启动诊断服务，在只读文件系统下创建诊断IPC socket失败直接抛错；二是创建非root用户时没有创建对应的home目录，.NET运行时初始化用户配置路径时找不到目录触发启动失败。

1. 调整Dockerfile配置 #

替换废弃的环境变量，补齐非root用户的目录权限，参考配置如下：

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 8080
# .NET 6及以上版本统一使用DOTNET_作为环境变量前缀，废弃旧版COMPlus_前缀
ENV ASPNETCORE_URLS=http://+:8080 \
    DOTNET_EnableDiagnostics=0 \
    DOTNET_TELEMETRY_OPTOUT=1 \
    TMPDIR=/tmp

# 创建非root用户时加-m参数自动生成home目录
RUN groupadd -g 2000 appgroup && \
    useradd -u 1000 -g 2000 -m -d /home/appuser appuser && \
    # 提前给运行时需要读写的目录授权
    chown -R 1000:2000 /app /tmp /var/tmp /home/appuser

# 保留原有应用发布、文件拷贝的逻辑，构建完成后切换非root用户运行
USER 1000:2000
ENTRYPOINT ["dotnet", "你的应用入口dll名称.dll"]

删除Program.cs里硬编码的ListenAnyIP(8080)配置，避免硬编码和环境变量配置冲突，Kestrel会自动读取ASPNETCORE_URLS的配置完成端口绑定。

2. 调整Helm Deployment安全配置 #

readOnlyRootFilesystem: true会直接将镜像内置的所有文件系统路径设为只读，哪怕构建时给目录授了权也无法写入，必须通过emptyDir挂载给需要写入的路径单独提供可写层，配置片段参考：

containers:
  - name: 你的容器名
    image: 你的应用镜像地址
    ports:
      - name: http
        containerPort: 8080
        protocol: TCP
    securityContext:
      runAsNonRoot: true
      runAsUser: 1000
      runAsGroup: 2000
      allowPrivilegeEscalation: false
      privileged: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL
    volumeMounts:
      # 给所有需要写入的路径挂载可写临时卷
      - name: tmp-dir
        mountPath: /tmp
      - name: var-tmp-dir
        mountPath: /var/tmp
      - name: app-user-home
        mountPath: /home/appuser
volumes:
  - name: tmp-dir
    emptyDir: {}
  - name: var-tmp-dir
    emptyDir: {}
  - name: app-user-home
    emptyDir: {}

注意securityContext里配置的runAsUser、runAsGroup必须和Dockerfile里创建的用户UID/GID完全一致，避免权限错位。

重新部署后进入Pod执行校验：

• 执行id确认当前运行用户为UID 1000、GID 2000的非root用户
• 执行printenv | grep -E 'ASPNETCORE_URLS|DOTNET_EnableDiagnostics'确认环境变量值和预期一致
• 查看Pod日志，出现Now listening on: http://0.0.0.0:8080字样即表示Kestrel启动正常

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