Skip to main content

Authentication

All requests to the Palmetto API must be authenticated. The API supports two authentication methods:

  • MUNGE: for scripts and applications running on Palmetto login or compute nodes
  • Bearer Token: for external integrations developed by node owners

Unauthenticated requests will be rejected.

MUNGE Authentication​

MUNGE authentication is the simplest method when your code runs directly on a Palmetto cluster node. Every cluster node runs the MUNGE daemon, so you can generate credentials without any setup.

How It Works​

  1. Generate a MUNGE credential using the munge command
  2. Send it in the Authorization header with the MUNGE scheme
  3. The API validates the credential and maps the UID to your Palmetto username

Example​

# List all jobs
curl https://api.palmetto.clemson.edu/slurm/latest/jobs \
  -H "Authorization: MUNGE $(munge -n -t 5)"
# Submit a job
curl https://api.palmetto.clemson.edu/slurm/latest/job/submit \
  -H "Content-Type: application/json" \
  -H "Authorization: MUNGE $(munge -n -t 5)" \
  -d '{
    "job": {
      "name": "test-job",
      "environment": [
        "PATH=/usr/local/bin:/usr/bin:/usr/local/sbin:/usr/sbin"
      ],
      "current_working_directory": "'$HOME'",
      "script": "#!/bin/bash\nhostname\nsleep 30\necho done",
    }
  }'

Scopes​

MUNGE-authenticated users receive broad access to the API with the same permissions as their user has with normal Slurm commands (e.g. sacct, squeue, scontrol, etc.).

Requirements​

  • The munge command must be available (installed on all Palmetto nodes)
  • Credentials must be created with a 5-second TTL (munge -n -t 5). The API rejects credentials with a longer TTL, so the default munge -n will not work
  • The credential must be generated on the same machine that makes the HTTP request.
  • Generate a fresh credential for each request. Credentials expire quickly

Bearer Token Authentication​

Bearer token authentication is for external integrations that run outside the cluster. Node owners can use bearer tokens to integrate their own applications and automation with the Palmetto API from outside the cluster. Tokens are issued by RCD staff and configured with specific scopes that limit what the token can access.

How It Works​

  1. Obtain a bearer token from RCD (token values are unique, non-guessable strings) using the process described in the node owner's guide.
  2. Send it in the Authorization header with the Bearer scheme.
  3. The API validates the token and applies the scopes and account restrictions assigned to it.

Example​

# List all jobs
curl -s -H "Authorization: Bearer abc123-your-token-here" \
  https://api.palmetto.clemson.edu/slurm/latest/jobs

Alternatively, you can use the Slurm-compatible header pair (useful for certain off-the-shelf software):

curl -s \
  -H "X-Slurm-User-Name: palmapi_bearer" \
  -H "X-Slurm-User-Token: abc123-your-token-here" \
  https://api.palmetto.clemson.edu/slurm/latest/jobs

Node Owner Scopes​

Node owner tokens are typically configured with these scopes:

ScopeDescription
slurm:readRead access to Slurm controller endpoints (jobs, nodes, partitions, etc.)
slurmdb:readRead access to SlurmDB accounting endpoints (job history, users, accounts, etc.)
slurm:jobs:manageSubmit, update, and cancel jobs

Account Restrictions​

Node owner bearer tokens are restricted to a single Slurm account — the account that allows submission to your node owner partition. This means write operations (job submit, job cancel, etc.) can only target jobs under that specific account.

MUNGE-authenticated users are not restricted to specific accounts.

Obtaining a Token​

Node owners can request a service account and bearer token for job submission through the Palmetto API. See the Node Owner's Guide for setup instructions.

Invalid Credentials​

  • Expired or malformed credentials return 401 Unauthorized
  • Insufficient scope for an endpoint returns 403 Forbidden
  • Account restriction violations return 403 Forbidden