Bamboo

Connect Bamboo to Team Server, install the Runtime Sensor on every build agent, and instrument each protected job with a start task and final stop task.

Object Mapping

Discover the plan before instrumenting it. Each job result becomes a build, identified by job key and build number. All jobs in a plan share one policy; separate plans can use different policies.

Prerequisites

• Operator or Administrator access to Team Server
• Bamboo access that can create a personal access token and edit plans
• Root access to local and remote agent hosts

Configure the Integration

Credentials and Permissions

Use a dedicated Bamboo service account with these permissions:

Under the account profile, open Personal access tokens and create a Read-only token. Do not select Triggering or Same as user because Team Server does not start builds or change Bamboo resources. The token can further restrict the account, but it cannot expose projects or plans the account cannot view.

Set an expiry and rotation owner; store the token in a secrets manager.

Add Bamboo to Team Server

1. Open Integrations, then Bamboo under Discover.
2. Select Get Started or Create.
3. Enter the Bamboo base URL and token.
4. Select Test, then Save.

Discovered plans appear under Pipelines. Create separate integrations for separate Bamboo instances or credentials. For a private address or internal CA, configure Team Server outbound HTTP policy.

Schedule Discovery

Add these jobs to scheduler.jobs:

bamboo_pipelines:
  run: "bamboo_sync mode:pipelines trigger:scheduled"
  schedule: "0 0 * * * * *"
bamboo_builds:
  run: "bamboo_sync mode:builds trigger:scheduled"
  schedule: "0 */15 * * * * *"

Keep statistics_calculate and status_reconcile enabled. Restart Team Server after changing configuration; see Scheduler.

Manage Sync and Deletion

Use Start Sync for an immediate run. See sync controls and deletion.

Install the Runtime Sensor on Agents

Install the Sensor on every Linux x86-64 local, remote, elastic, or autoscaled agent eligible for protected jobs. Include it in agent images/provisioning and check capability-based or dedicated-agent placement.

Keep license, token, and Team Server URL in root-only host configuration; build steps need only unprivileged job commands. Verify endura sensor status and root-only endura sensor hooks on each agent.

Instrument a Job

A Bamboo plan contains stages, jobs, and tasks. Instrument each job that performs protected work.

Start Task

Under the job’s Tasks, add a Script task as the first task, before every Source Code Checkout task:

set -e

# Start protection before source checkout.
ENDURA_JOB_ID=$(endura job start)
echo "started endura job with id ${ENDURA_JOB_ID}"

Bamboo supplies the workspace, plan, job, branch, and manual-trigger metadata through its native bamboo_* variables; no generic metadata exports are needed. The manual-trigger username can be empty for other triggers. Keep set -e so startup failure stops the task before checkout.

Final Stop Task

Under Final tasks, add a Script task:

endura job stop

Final tasks provide cleanup and derived-policy output after task failures. Force cancellation can skip them; cancellation retirement provides a fallback when the Sensor survives.

Bamboo Specs

Use repository-stored Bamboo Specs to standardize the tasks:

version: 2
plan:
  project-key: PROJ
  key: BUILD
  name: Example Build
stages:
  - Build:
      jobs:
        - Build
Build:
  tasks:
    - script:
        description: Start Endura Job
        interpreter: SHELL
        scripts:
          - |
            set -e

            # Start protection before source checkout.
            ENDURA_JOB_ID=$(endura job start)
            echo "started endura job with id ${ENDURA_JOB_ID}"
    # Run existing protected build tasks here.
  final-tasks:
    - script:
        description: Stop Endura Job
        interpreter: SHELL
        scripts:
          - endura job stop

Apply the same pattern to every job defined by the Specs. Keep each Source Code Checkout task after Start Endura Job.

Docker Runner Jobs

When Bamboo uses its Docker Runner, one container runs the job’s process-based tasks. The Runtime Sensor remains on the agent host. Add this Docker volume argument to the job:

--volume /run/endura/sensor.sock:/run/endura/sensor.sock

Install the CLI in the first task before starting the job:

set -e

# Install the CLI inside the container.
curl -sSf https://repo.endurasecurity.com/install/endura-sensor/testing.sh | sh

# Start protection through the host Sensor.
ENDURA_JOB_ID=$(endura job start)
echo "started endura job with id ${ENDURA_JOB_ID}"

Keep endura job stop as a final task. Without the socket mount, the CLI cannot reach the Runtime Sensor on the host.

Multi-job Plans

Instrument every job on every agent. Each execution becomes a build; jobs in a plan share its policy. Derive across the full plan. Split jobs into separate plans when they need different policies.

Verify

1. Run the complete plan.
2. Open the Bamboo plan under Pipelines in Team Server.
3. Confirm each instrumented job appears under Builds.
4. Confirm each selected agent reports the expected Team Server connection and hook coverage.
5. If a build is missing, check plan discovery, agent capabilities, task order, and final-task logs.

Troubleshooting

Create and Assign a Policy

Derive across representative plans and all their jobs and capture the policy printed by endura job stop. Refine and test it in observe mode, then assign it to the Bamboo plan pipeline before enforcement.

Configure notifications after violations reach Team Server.