agent-init init container failed due to the pod level security context

[rickyzhang82]

Describe the bug

I tried to debug security hardening Airflow pod. At the pod level, it has the following security context

  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault

So, I overrode the side care agent container security context with the following values:

telepresence helm install -f values.yaml

agent:
  securityContext: 
    allowPrivilegeEscalation: true
    runAsNonRoot: false

But the init container failed

telepresence intercept sas-airflow-webserver --port 8080:8080 --env-file ~/.tpenv/sas-airflow-webserver.env
telepresence intercept: error: connector.CreateIntercept: Error: container has runAsNonRoot and image will run as root (pod: "sas-airflow-webserver-7f65b4f656-qlk28_d22271(b030cb0f-f5c9-4e3f-a7a8-8b308c6abab3)", container: tel-agent-init)
Hint: if the error mentions resource quota, the traffic-agent's requested resources can be configured by providing values to telepresence helm install

  tel-agent-init:
    Container ID:  
    Image:         ghcr.io/telepresenceio/tel2:2.20.3
    Image ID:      
    Port:          <none>
    Host Port:     <none>
    Args:
      agent-init
    State:          Waiting
      Reason:       CreateContainerConfigError
    Ready:          False
    Restart Count:  0
    Environment:
      LOG_LEVEL:  info
      POD_IP:      (v1:status.podIP)
    Mounts:
      /etc/traffic-agent from traffic-config (rw)

To Reproduce
Steps to reproduce the behavior:

1. When I run 'telepresence intercept' for the pod with securityContext runAsNonRoot: true, the init container failed.

Expected behavior
The init container should pass or inherit the overrode security context from values.yaml

Versions (please complete the following information):

• Output of telepresence version v2.20.3
• k8s

Client Version: v1.30.4
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.2

[thallgren]

I don't think the init-container should inherit the traffic-agent's securityContext. They have different requirements. The traffic-agent doesn't need any elevated privileges to run. The tel-init-container however, needs the NET_ADMIN capability in order to use iptables. So perhaps what's needed here is the ability to pass a separate securityContext for the tel-agent-init.

[rickyzhang82]

@thallgren, I second your point.

In my use case, I need to debug an Airflow scheduler pod that has no service and no exposed container port to the outside. The Airflow architecture is built on top of a database. There is no incoming traffic in the scheduler. So I have to fake a mock container port. This requires the tel-init container to run as root. Thanks to the dev doc, I figured out how to patch it with a dirty fix and push it to a private registry.

But the alternative is that we don't require the port option when telepresence intercept. The Airflow scheduler is a good case in point. There are no container ports. The service only needs to intercept outgoing local traffic and corresponding returned traffic from k8s.

[thallgren]

Looks like you would benefit from the new telepresence ingest command that was introduced in 2.21.0 and this fix released in 2.21.1 that removes the need for a port altogether.

I'm curious what it was that you patched. Is there something we can do to support it in telepresence?

[rickyzhang82]

The ingest seems to be exactly what I need. My fix is just hard-code the additional security context so that it overwrites the hardening security context at the pod level:
release/v2...rickyzhang82:telepresence:v2.20.3-hack