Workload Identity

---

A Chalk workload identity applies to sandboxes, scaling groups, and functions. Each one receives an identity only when you set chalk_identity=True from the SDK, or pass --chalk-identity from the scaling group CLI.

---

​

Enabling a workload identity

With chalk_identity=True, Chalk mounts a Chalk token into the container and sets CHALK_WEB_IDENTITY_TOKEN_FILE, CHALK_API_SERVER, and CHALK_ENVIRONMENT. ChalkClient and chalkcompute read these variables, so code in the container can call Chalk APIs without a client ID or secret.

A sandbox:

from chalkcompute import Image, Sandbox

sandbox = Sandbox(image=Image.debian_slim(), chalk_identity=True).run()
result = sandbox.exec("sh", "-c", "echo $CHALK_WEB_IDENTITY_TOKEN_FILE")
print(result.stdout_text)  # /var/run/secrets/chalk/identity-token
sandbox.terminate()

A scaling group:

import chalkcompute

img = chalkcompute.Image.debian_slim("3.12").entrypoint(
    ["python", "-m", "http.server", "8080"]
)

sg = chalkcompute.ScalingGroup(
    image=img,
    name="hello-api",
    port=8080,
    chalk_identity=True,
).deploy()

A function takes the same argument, @chalkcompute.function(chalk_identity=True), and passes it to the scaling group it runs on.

---

​

OIDC federation

Chalk workload identities are OIDC-compliant. If your organization runs services that accept federated tokens (e.g. an internal model registry or a secrets manager), you can configure them to trust the Chalk identity provider directly. This lets a workload authenticate to your infrastructure without static credentials:

1. Register the Chalk OIDC issuer as a trusted identity provider in your service.
2. Map the workload’s sub claim to an appropriate role or policy.
3. The workload can then exchange its identity token for access to your service at runtime.

No secrets need to be injected into the workload’s environment.