Configuring Workload Identity Federation for Generic OIDC Providers

Step 1: Navigate to Identity Providers

Navigate to IAM → Identity Providers in your Thalassa Cloud Console.

Step 2: Create Generic OIDC Identity Provider

Click “Create Identity Provider” and configure:

Basic Information:

• Name: Choose a descriptive name (e.g., google-cloud, azure-ad, okta)
• Description: Optional description of the identity provider’s purpose

OIDC Configuration:

• OIDC Issuer URL: Enter your identity provider’s issuer URL
  • This must be the exact issuer URL as returned by your OIDC provider
  • Examples:
    • Google Cloud: https://accounts.google.com
    • Azure AD: https://login.microsoftonline.com/{tenant-id}/v2.0
    • Okta: https://{your-domain}.okta.com/oauth2/default

JWKS Configuration: Choose one of the following options:

Option A: Automatic Discovery (Recommended)

If your OIDC provider supports well-known configuration discovery:

• Leave JWKS endpoint blank
• Thalassa Cloud will automatically fetch the JWKS endpoint from: {issuer-url}/.well-known/openid-configuration
• This works for most standard OIDC providers

Option B: Custom JWKS Endpoint

If automatic discovery doesn’t work or you need to specify a custom endpoint:

• Specify the JWKS endpoint URL directly
• Example: https://your-issuer-url/.well-known/jwks.json
• Use this if your provider uses a non-standard JWKS location

Option C: Custom JWKS JSON (Offline Use)

For air-gapped environments or when you need to pin specific keys:

• Provide the JWKS JSON content directly
• Format:

  {
    "keys": [
      {
        "kty": "RSA",
        "use": "sig",
        "kid": "key-id",
        "n": "modulus-value",
        "e": "exponent-value"
      }
    ]
  }
• Important: When keys rotate, you must manually update this content

Step 3: Save Identity Provider

Click “Create Identity Provider” to save the configuration.

Step 1: Navigate to Service Accounts

Navigate to IAM → Service Accounts in your Thalassa Cloud Console.

Step 2: Select Service Account

Select the service account you want to configure for OIDC federation.

Step 3: Create Federated Identity

Click “Add Federated Identity” or “Workload Identity Federation”.

Step 4: Configure Token Matching

Configure how tokens from your OIDC provider are matched:

Identity Provider:

• Select the identity provider you created in Step 2

Token Matching:

The subject claim (sub) is the primary claim used for matching. The format varies by provider:

• Standard Format: sub:user-id or sub:service-account-id
• Provider-Specific Formats: Some providers use unique formats:
  • Google Cloud: serviceAccount:PROJECT-ID@PROJECT-ID.iam.gserviceaccount.com
  • Azure AD: {object-id} or {upn}
  • Okta: {user-id} or custom format

Understanding Your Provider’s Claims:

To determine the correct subject claim format:

1. Obtain a token from your OIDC provider
2. Decode the token to inspect claims:

   # JWT tokens have three parts separated by dots
   echo "YOUR_TOKEN" | cut -d. -f2 | base64 -d | jq
3. Identify the sub claim and its format
4. Use this format in your federated identity configuration

Subject Claim Examples:

• Match specific user: user:john.doe@example.com
• Match service account: serviceAccount:my-project@my-project.iam.gserviceaccount.com
• Match with wildcards: serviceAccount:*@my-project.iam.gserviceaccount.com
• Match by domain: *@example.com

Additional Claims (optional):

Many OIDC providers include additional claims you can match:

• email: User email address
• aud: Audience (should match your API endpoint)
• iss: Issuer (must match your configured issuer)
• exp: Expiration time
• iat: Issued at time
• Provider-specific claims (e.g., groups, roles, tenant)

API Scopes:

• Select the API scopes your application needs (e.g., read, write)
• Follow the principle of least privilege

Expiry (Optional):

• Set an expiry date if this is a temporary federation

Step 5: Save Federated Identity

Click “Create Federated Identity” to complete the setup.