skip to Main Content

we have an EKS cluster on 1.21.

There is an nginx-ingress-controller-default-ingress-controller deployed with a Classic Load Balancer.

Suddenly, its pods are crashing with following errors.

I0815 04:40:04.970835       8 flags.go:204] Watching for Ingress class: nginx
W0815 04:40:04.980149       8 flags.go:249] SSL certificate chain completion is disabled (--enable-ssl-chain-completion=false)
W0815 04:40:04.980218       8 client_config.go:543] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
W0815 04:40:04.980255       8 client_config.go:548] error creating inClusterConfig, falling back to default config: open /var/run/secrets/kubernetes.io/serviceaccount/token: permission denied
F0815 04:40:04.980417       8 main.go:272] Error while initiating a connection to the Kubernetes API server. This could mean the cluster is misconfigured (e.g. it has invalid API server certificates or Service Accounts configuration). Reason: open /var/run/secrets/kubernetes.io/serviceaccount/token: permission denied

Below are the securityContext and VolumeMount of the pod.

 securityContext:
      allowPrivilegeEscalation: true
      capabilities:
        add:
        - NET_BIND_SERVICE
        drop:
        - ALL
      runAsUser: 101
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-k7n9n
      readOnly: true

I tried to change runAsUser : 0, but it throws back with message the pods ".." is invalid.

Can you please give me some directions on what can be wrong here and any possible solution?

2

Answers


  1. Try adding fsGroup. This will make serviceaccount directory readable by non-root user:

    spec:
      template:
        spec:
          securityContext:
            fsGroup: 65534
    
    Login or Signup to reply.
  2. Go to your nginx controller DaemonSet and include the fsGroup with value 65534 to help you run the container for non-root user.

    When you run containers with non-root users (a security best practice), you might encounter permission issues when writing to volume-mounted directories, especially if the containerized application expects to write files with specific permissions. Setting fsGroup: 65534 can help prevent permission issues by ensuring that the files created in the volume are not owned by any privileged group.

    spec:
      template:
        spec:
          securityContext:
            fsGroup: 65534
    
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search