Skip to content

Issuer Subject Already Bound

URI: https://docs.ankatech.co/errors/issuer-subject-already-bound
HTTP Status: 409 Conflict

When you see this

A federation binding names a trusted issuer and an exact subject that are already bound to an administrative workload or a cryptographic actor of the same tenant. One external identity authenticates as one principal only, so nothing was stored.

Common Causes

  • The subject is already bound to another workload of the tenant.
  • The subject is bound to a cryptographic actor of the tenant (the actor issuer-binding operations refuse a pair already bound to a workload the same way).
  • The same binding was created twice.

Response Example

{
  "type": "https://docs.ankatech.co/errors/issuer-subject-already-bound",
  "title": "Issuer Subject Already Bound",
  "status": 409,
  "detail": "This issuer and subject are already bound to an administrative workload or a cryptographic actor of this tenant. Remove that binding first.",
  "instance": "/api/v3/admin/tenants/7d2f4a10-9c31-4b8e-a5d6-2f11c0b47e93/workloads/9b2f6c1e-3d4a-4c8b-a1e7-5f0d2c9b8a71/issuer-bindings",
  "timestamp": 1730000000,
  "extensions": {
    "requestId": "550e8400-e29b-41d4-a716-446655440000"
  }
}

Content-Type: application/problem+json — the response follows RFC 9457 Problem Details.

How to Resolve

  1. Find the workload or actor that holds the binding and remove it there, then bind it again.
  2. Or give the workload its own subject at the external issuer (for example its own Kubernetes service account).

For full schema definitions, examples, and interactive testing, see the Developer Hub Reference.