Skip to content

[Gap]: Okta reference architecture for Stacklok Enterprise, with Terraform #1292

Open

Description

@danbarr

What needs documentation?

A reference architecture page for configuring Okta with Stacklok Enterprise, built around working Terraform for the Okta side and the matching Enterprise Manager Helm values.

Today, Okta setup is spread across guides as prose and admin console click paths, which drift whenever Okta redesigns its UI. Only one guide has a code example: the attribute mapping snippet in okta-directory-sync.mdx (#1291). A complete, tested configuration would give admins something to adapt, not something to piece together.

Candidate scope:

  • Directory sync, pull reconciler: the target app, the service app with private_key_jwt and its API scopes, the custom admin role and resource set, the app user schema properties with SCIM destinations, and the profile mappings.
  • Directory sync, push SCIM: the SCIM app, bearer token, To App mappings, and Group Push.
  • Sign-in: the console's authorization server and the audience, claims, and uid binding the directory issuer expects.
  • Connector Gateway identity provider apps: where Okta is the upstream IdP.
  • Matching values: the enterprise-manager.directory values for each pattern.

Context and references

  • docs/platform/enterprise-directory/okta-directory-sync.mdx
  • docs/platform/enterprise-directory/scim-provisioning.mdx

Things to settle:

  • Placement: a reference page under platform/, linked from the directory guides, so how-to pages stay task-sized.
  • Maintenance: state the Okta provider version the examples were tested against, and consider extracting the HCL blocks and running terraform validate in CI, the way YAML examples are dry-run against CRDs.
  • Highlighting: HCL code blocks currently render unhighlighted (see Fix Stacklok Enterprise docs gaps from demo walkthrough #1291).

Use case

As a platform admin setting up Stacklok Enterprise with Okta, I want a complete, tested Terraform configuration to start from, so I don't have to reverse-engineer which apps, scopes, roles, schema properties, and mappings each feature needs from several guides.

Fully or partially written by an AI agent.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or requestneeds-triageIssue needs initial triage by a maintainer

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions