Issue#2834: Agent Impersonation via JENKINS_SECRET

[mladjan-gadzic]

Testing done

Closes #2834

Replaced JENKINS_SECRET env var value from plain text to K8s secret in JNLP container. It is created after pod is created with pod as owner. Pod waits for secret removal before it is deleted.

Unit test provided.

Manul test showing part of the output of command kubectl describe pod xxx after the fix where jnlp container env vars are shown

Environment:
      JENKINS_SECRET:         <set to the key 'jenkins-secret' in secret 'job-5-45dsn-k1lb8-g3854-jnlp-secret'>  Optional: false
      REMOTING_OPTS:          -noReconnectAfter 1d
      JENKINS_AGENT_NAME:     job-5-45dsn-k1lb8-g3854
      JENKINS_NAME:           job-5-45dsn-k1lb8-g3854
      JENKINS_AGENT_WORKDIR:  /home/jenkins/agent
      JENKINS_URL:            http://host.docker.internal:8080/jenkins/

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[jglick]

Interesting trick, but seems to be addressing what I consider a misconfiguration rather than a vulnerability, and would require the Jenkins controller to have create secrets permission in the agent namespace which it otherwise normally would not.