What Marathoon protects today
Marathoon does not offer a managed secret store for pipelines yet: there is no place to save an organization secret and have it injected into your jobs. Managed pipeline secrets are under consideration — see the roadmap.
What the platform does protect are the credentials you give it to reach your own systems:
- Storage credentials for your S3 bucket, MinIO endpoint or Azure Blob container
- Private registry credentials attached to a Connected Runner provider
- SSO client secrets for your identity provider
They are encrypted at rest at the application level (AES-256-GCM, with a key kept outside the database — or stored in a Key Vault when the deployment uses one), never returned by the API and never displayed again once saved. API keys are stored only as hashes and shown once, at creation.
Connect your infrastructure without over-sharing
Everything starts from Settings → Infrastructure → Connect infrastructure (step by step in Connect your own infrastructure):
- Runner — the machine enrols with a one-time token (15 minutes, single use) and receives an API key limited to the runner endpoints and bound to that machine.
- Storage — enter the credentials of a dedicated identity built from the least-privilege policy the form generates. Better still, pick Cross-account role (AWS) or Managed identity (Azure): no key is shared at all, and you revoke access on your side.
- Private registry — use a read-only token scoped to the images you run. It is handed to the runner only for jobs whose image lives on that registry.
Keep secrets out of jobs and images
- Never bake a secret into a Docker image: anyone who can pull the image can read it.
- Never put a secret value in job inputs, parameters or environment variables: they are stored with the pipeline or the job, visible to project members and returned by the API.
- Run sensitive workloads on your own infrastructure. A job on your Connected Runner runs inside your network, so it can rely on access that machine already has — a cloud instance role, an internal vault — without that credential ever passing through Marathoon. With direct storage transfer enabled, job files don't pass through Marathoon either.
Checklist
- One dedicated, least-privilege identity per storage or registry connection
- Prefer role-based access (AWS role, Azure managed identity) over long-lived keys
- Give each API key the smallest permission preset that works, and an expiry date
- Revoke the runners and keys you no longer use; rotate credentials after any suspected exposure