Creating Platform Administrators

Grant the first Platform Administrator role from the command line. That administrator can then appoint others in the Platform Admin Console. The chart does not assign this role automatically.

Use email-based bootstrap for Zitadel or eligible verified-email accounts. For accounts imported by immutable subject, use Grant to a prepared subject.

Prerequisites

• kubectl access to the namespace where the Identity Service runs.
• Use the Identity Service image shipped with the current chart.
• The istari-identity and docker-pull-secret secrets. If yours have other names, change them in the command.
• Prepare the account and tenant membership. Zitadel and Keycloak require verified email for email-based bootstrap; Entra, Google, and Lastwall use subject mappings.
• The tenant they sign in to: one the chart's Zitadel import created, named by its Zitadel organization's ID (how to find it), or one you created, named by its slug with -tenant.

Email-based bootstrap

1. Run ensure-platform-admins as a one-off pod. Replace <tag> with your Identity Service image tag, <organization id> with the organization's ID, and <email> with the person's address. For a tenant you created, replace "-organization","<organization id>" with "-tenant","<tenant slug>"; under Zitadel with ENROLLMENT_POLICY set to pre-registered-only rather than the default open, that tenant must first be mapped to the person's Zitadel organization, or their sign-in is refused. Set -provider to the selected provider (zitadel, keycloak, entra, okta, pingfederate, lastwall, or google). Add -n <namespace> if the Identity Service isn't in your current namespace.

   kubectl run ensure-platform-admins --rm -i --restart=Never \
     --image=istaridigital.jfrog.io/customer-docker/identity-service:<tag> \
     --overrides='{
       "spec":{
         "imagePullSecrets":[{"name":"docker-pull-secret"}],
         "containers":[{
           "name":"ensure-platform-admins",
           "image":"istaridigital.jfrog.io/customer-docker/identity-service:<tag>",
           "command":["/ensure-platform-admins"],
           "args":["-database-url-env","ISTARI_DIGITAL_IDENTITY_SERVICE_DATABASE_URL",
                   "-organization","<organization id>",
                   "-provider","zitadel",
                   "-email","<email>"],
           "envFrom":[{"secretRef":{"name":"istari-identity"}}]
         }]}
     }'

   Flag	Meaning
   -email	A person to make a Platform Administrator. Repeat "-email","<email>" for each person.
   -organization	The Zitadel organization whose tenant they sign in through. Anyone the command doesn't know yet is pre-registered there.
   -tenant	The tenant's slug, in place of -organization.
   -provider	The selected upstream provider; use the same provider as the prepared account mapping.

   Running it again is safe: it never removes the role from anyone.

2. Check the output, one line per address:

   Output	Meaning
   <email>: pre-registered and granted the platform administrator role, principal <id>	Nobody had this address. Their first sign-in through the organization takes over the new record.
   <email>: granted the platform administrator role, principal <id>	They now hold the role.
   <email>: principal <id> already holds the platform administrator role	Nothing to do.
   WARNING: <email> skipped: <reason>	Nothing granted; the reason says why.

   • Someone in another organization's tenant is skipped. Run the command once per organization.
   • A suspended person is skipped. Reinstate them first.
   • A person the chart's Zitadel import created is skipped until they have signed in once. Have them sign in, then run the command again.
   • WARNING: no platform administrator exists at the end means nobody holds the role yet. Fix the skipped addresses and run it again.

3. Verify. Each person signs in at https://<customer_istari_fqdn> and can open the Platform Admin Console.

Grant to a prepared subject

Use grant-platform-role for an existing account linked by provider subject. Confirm the subject and tenant membership first; the command creates neither.

Run the following one-off pod, substituting your Identity Service image tag, selected provider, and that person's immutable upstream ID (oid for Entra, sub for Google, Lastwall, Okta, or PingFederate):

kubectl run grant-platform-admin --rm -i --restart=Never \
  --image=istaridigital.jfrog.io/customer-docker/identity-service:<tag> \
  --overrides='{
    "spec":{
      "imagePullSecrets":[{"name":"docker-pull-secret"}],
      "containers":[{
        "name":"grant-platform-admin",
        "image":"istaridigital.jfrog.io/customer-docker/identity-service:<tag>",
        "command":["/grant-platform-role"],
        "args":["-database-url-env","ISTARI_DIGITAL_IDENTITY_SERVICE_DATABASE_URL",
                "-upstream-provider","<provider>",
                "-upstream-user-id","<immutable upstream ID>",
                "-role","admin"],
        "envFrom":[{"secretRef":{"name":"istari-identity"}}]
      }]}
  }'

Check that the grant names the expected principal and that the person can open the Platform Admin Console.

Use this command when ensure-platform-admins skips a subject-imported account whose email has not been verified at sign-in.