Jenkins Plugins and Agents
Jenkins ships with a deliberately small core, and almost every feature you associate with a real Jenkins deployment — Git integration, Docker support, Kubernetes-based dynamic agents, Slack notifications, credential types, Blue Ocean's visual pipeline editor — arrives as a plugin. This plugin-first architecture is a double-edged sword: it makes Jenkins extraordinarily adaptable to nearly any tooling ecosystem, since the plugin catalog numbers in the thousands, but it also makes plugin management itself a significant, ongoing operational responsibility, since plugin updates, deprecations, and interdependencies are a leading cause of Jenkins upgrade pain and CVEs.
Cricket analogy: A stadium built with a bare minimum of permanent structure and almost every feature — floodlights, hospitality boxes, the giant screen — bolted on later as add-on modules is wildly adaptable to any event, but managing dozens of third-party vendor installations becomes its own ongoing headache and safety risk.
How plugins extend Jenkins
Plugins are installed through the 'Manage Jenkins > Plugins' UI or, for reproducible controller setup, via jenkins-plugin-cli / a plugins.txt file baked into a custom Docker image at build time — the latter is strongly preferred for production because it makes plugin versions explicit, auditable, and identical across environments rather than drifting based on whatever was clicked in the UI over time. Plugins can add new pipeline steps (e.g. the Kubernetes plugin's podTemplate), new credential types (e.g. the AWS Credentials plugin), new SCM integrations, new build triggers, and entirely new UI panels. Because plugins run inside the controller's JVM with broad access, a malicious or buggy plugin is effectively a controller-level risk, which is why plugin provenance (only installing from the official Jenkins Update Center) and keeping plugins patched matters as much as patching Jenkins core itself.
Cricket analogy: Clicking together a squad by picking whoever's available in the changing room each match day is like installing plugins through the UI ad hoc, whereas naming a fixed, written squad list at the start of the season — auditable, identical for every match — is like baking a plugins.txt into the build; and letting an unvetted player onto the field is a whole-team risk since they share the same dressing room and equipment.
Static vs SSH vs dynamic cloud agents
Agents fall into three broad provisioning patterns. Static agents are long-lived machines manually registered with the controller and connected via the JNLP/inbound TCP agent protocol — simple to set up but requiring manual capacity planning and patching. SSH-launched agents flip the connection direction: the controller initiates an SSH connection out to a known host and launches the agent process remotely, which is convenient when agents live behind a controller-reachable network boundary and avoids opening inbound ports on the agent side. Dynamic cloud agents, provisioned by plugins such as the Kubernetes plugin, the EC2 plugin, or the Azure VM Agents plugin, are created on demand when a build needs one and destroyed afterward — trading a small provisioning-latency cost for elastic capacity and strong build-to-build isolation, since no state persists between ephemeral agents unless explicitly cached.
Cricket analogy: Static agents are like permanent groundstaff hired year-round regardless of the match schedule — reliable but needing constant upkeep; SSH-launched agents are like the home ground calling in a specific local umpire only when needed, avoiding the visiting team having to arrange anything; dynamic cloud agents are like hiring a fresh pitch crew for a single day-night match and releasing them straight after, trading a short setup delay for zero long-term overhead.
# Kubernetes plugin: podTemplate defining a dynamic agent pod
# used inside a Jenkinsfile's agent { kubernetes { yaml ... } } block
apiVersion: v1
kind: Pod
spec:
containers:
- name: maven
image: maven:3.9-eclipse-temurin-17
command: ['cat']
tty: true
- name: docker
image: docker:24-cli
command: ['cat']
tty: true
volumeMounts:
- mountPath: /var/run/docker.sock
name: docker-sock
volumes:
- name: docker-sock
hostPath:
path: /var/run/docker.sockA Kubernetes-agent pod can define multiple containers, each acting like a distinct tool 'workstation' sharing the same pod workspace — a Jenkinsfile step like container('maven') { sh 'mvn package' } runs that command specifically inside the maven container, letting a single build stage cleanly use several tool images (e.g. Maven for build, a Docker CLI container for image builds) without installing every tool onto one monolithic agent image.
The single most cited Jenkins operational risk in security audits is the combination of an outdated plugin set and unrestricted script execution (Groovy sandbox escapes, or the Script Console being reachable by non-admins). Regularly updating plugins, restricting who can access Manage Jenkins > Script Console, and enabling the Groovy sandbox for pipeline scripts are baseline hardening steps, not optional extras.
As Jenkins deployments mature, two forms of sprawl tend to appear: dozens of installed plugins where only a handful are actually load-bearing, and a heterogeneous zoo of manually-configured static agents with inconsistent tool versions. The Plugin Usage plugin (or manual audit against plugins.txt) helps identify and remove unused plugins, shrinking the attack surface and upgrade burden. On the agent side, migrating toward container-based dynamic agents defined declaratively (pod templates, Docker images) turns 'what tools does this agent have' from a manually-maintained fact about a specific machine into a versioned artifact reviewed in the same pull requests as the Jenkinsfile itself.
Cricket analogy: Over years a club accumulates dozens of specialist coaches on the payroll when only a handful actually get used on matchday, and a mismatched fleet of training grounds each with slightly different pitch conditions; auditing and cutting the unused coaches shrinks the wage bill, while moving to a single standardized, documented pitch spec reviewed alongside the season plan turns "what surface do we train on" from tribal knowledge into a written, versioned fact.
- Jenkins core is intentionally minimal; almost all real functionality — SCM, notifications, credential types, cloud agents — comes from plugins.
- Pin plugin versions via a
plugins.txt/plugin-cli baked into the controller image for reproducibility, rather than relying on ad hoc UI installs. - Static agents are long-lived and manually managed; SSH agents are controller-initiated; dynamic cloud agents (Kubernetes, EC2, etc.) are provisioned per-build and torn down after.
- Kubernetes agent pods can host multiple containers, letting a pipeline stage target specific tool containers within one pod.
- Outdated plugins and unrestricted Script Console access are leading Jenkins security risks — patch plugins and restrict access regularly.
- Auditing and removing unused plugins, and moving to declarative container-based agents, reduces both attack surface and configuration drift.
Practice what you learned
1. Why is installing Jenkins plugins via a version-controlled `plugins.txt` baked into a custom controller image generally preferred over ad hoc UI installation in production?
2. What distinguishes an SSH-launched agent from a JNLP/inbound agent?
3. In a Kubernetes plugin pod template with multiple containers, how does a Jenkinsfile step target a specific container?
4. Which combination is cited as a leading Jenkins security risk in audits?
5. What operational tradeoff do dynamic cloud agents (e.g. Kubernetes-provisioned) make compared to static agents?
Was this page helpful?
You May Also Like
Jenkins Architecture Basics
Understand Jenkins' controller/agent architecture, how builds are distributed to executors, and the core components — controller, agents, executors, and the job queue.
Jenkinsfile Fundamentals
Learn the core building blocks of a Jenkinsfile — agent, stages, steps, environment, parameters, and post — and how Pipeline as Code changed Jenkins pipeline management.
Declarative vs Scripted Pipelines
Compare Jenkins' two pipeline authoring styles — the structured, opinionated declarative syntax versus the fully programmable Groovy-based scripted syntax — and when to reach for each.
Least Privilege for CI/CD Service Accounts
CI/CD service accounts should hold only the exact permissions their pipeline needs, scoped narrowly and time-limited, so a compromised job can't cascade into a broader breach.
Related Reading
Related Study Notes in DevOps
Browse all study notesNginx Study Notes
DevOps · 30 topics
DevOpsAnsible Study Notes
DevOps · 30 topics
DevOpsAdvanced Kubernetes Study Notes
Kubernetes · 30 topics
DevOpsAdvanced Bash Scripting Study Notes
Bash · 30 topics
DevOpsApache Kafka Study Notes
Kafka · 30 topics
DevOpsDocker & Kubernetes Study Notes
YAML · 40 topics