Skip to main content

Bot Trust Conditions Now Support Custom OIDC Providers

· 3 min read
Takashi Yoneuchi
Takashi Yoneuchi
CTO @ GMO Flatt Security Inc.

Bot trust conditions now accept ID tokens from any identity provider that complies with OIDC Discovery, not just GitHub Actions and GitLab CI.

Self-hosted CI/CD systems such as Jenkins, Buildkite, and CircleCI, another cloud's workload identity federation, GitHub Enterprise Server, and self-managed GitLab can all sign in as a bot without a static API key.

info

Custom OIDC provider support is currently in beta. Specifications and behavior may change without prior notice.

Overview​

A trust condition is a rule, configured on a bot, that decides which OIDC ID tokens Shisho Cloud accepts as proof that the caller may sign in as that bot. Until now it understood two issuers, GitHub Actions and GitLab CI, so every other environment had to fall back on a bot API key - a static secret you have to store, rotate, and keep out of your logs.

The new Custom (OIDC) provider lets you point a trust condition at your own issuer instead. Your identity provider mints a short-lived ID token for each job, Shisho Cloud verifies it against the condition, and exchanges it for equally short-lived credentials scoped to that bot. Nothing persistent has to live on the CI side.

Getting Started​

Open a bot's Trust Conditions tab in the Shisho Cloud console, add a trust condition, and select Custom (OIDC) as its provider. The condition takes three required inputs, plus an optional one.

  • Issuer - the https:// URL of the ID token's issuer. It must be reachable on port 443 and serve an OIDC Discovery document at /.well-known/openid-configuration.
  • Subject - the expected value of the ID token's sub claim, either an exact string or an expression in which * matches any sequence of characters, such as repo:acme/app:*. A subject of just * is rejected.
  • Audience - the value the ID token's aud claim must contain. We recommend configuring your provider to issue https://sts.cloud.shisho.dev, so a token minted for Shisho Cloud can't be replayed against another relying party.
  • Claims (optional) - up to 10 additional conditions on other top-level string claims of the token, each matched the same way as Subject.

Once the condition is saved, the CI-side flow is the same as for GitHub Actions or GitLab CI. Obtain an ID token from your provider, then pass it to shishoctl auth signin:bot.

Limit

An organization can have one custom OIDC trust condition in total, across all of its bots. GitHub Actions and GitLab CI trust conditions are not limited.

If you need more than one, contact support - whether we can accommodate the request depends on your plan.

For the full field reference, an example configuration, and security guidance, see Custom OIDC in the bot authentication guide.