generated: '2026-09-12'
method: searched
source: >-
  https://docs.solo.io/gloo-mesh-enterprise/latest/setup/prod/resource-control/ ,
  https://docs.solo.io/gloo-mesh-enterprise/latest/setup/prod/certs/relay/ ,
  https://docs.solo.io/gloo-mesh-enterprise/latest/setup/prepare/licensing/ ,
  https://docs.solo.io/gloo-mesh-enterprise/latest/reference/permissions/
docs: https://docs.solo.io/gloo-mesh-enterprise/latest/setup/prod/resource-control/
note: >-
  There is no Solo.io-operated API endpoint to obtain a key for. Gloo Mesh runs entirely in
  the customer's own Kubernetes clusters, so the identity plane is Kubernetes': you
  authenticate to YOUR cluster and Kubernetes RBAC decides what Gloo custom resources you may
  read or write. The provider-issued credential is a product LICENSE key, which gates
  features rather than access. The one Solo.io-hosted endpoint in this record, the Docs MCP
  server, requires no authentication at all.
summary:
  types: [kubernetes-rbac, mutual-tls, license-key, oidc]
  api_key_in: []
  oauth2_flows: []
  provider_hosted_auth_endpoint: false
schemes:
  - name: Kubernetes RBAC (primary)
    type: kubernetes-rbac
    applies_to: every Gloo custom resource in the 13 CRD API groups
    description: >-
      Clients (kubectl, Helm, meshctl, Argo CD, any controller) authenticate to the
      Kubernetes API server with the cluster's own mechanism and are authorized by Role /
      ClusterRole bindings on the Gloo CRD groups. Solo documents how to scope user access to
      Gloo resources and publishes the permissions the Gloo components themselves require.
    docs:
      - https://docs.solo.io/gloo-mesh-enterprise/latest/setup/prod/resource-control/
      - https://docs.solo.io/gloo-mesh-enterprise/latest/reference/permissions/
  - name: Relay mTLS
    type: mutualTLS
    applies_to: management server <-> workload cluster agent (the relay channel)
    description: >-
      Agents authenticate to the management server with client certificates over mTLS. Solo
      documents five postures — self-signed certs with managed client certs, BYO server cert
      with managed client cert, BYO server and client certs, TLS-only, and an insecure test
      mode — plus a relay identity token secret and full certificate-rotation guidance, with
      OpenSSL, AWS Private CA and HashiCorp Vault integrations.
    secrets:
      - relay-root-tls-secret
      - relay-tls-signing-secret
      - relay-server-tls-secret
      - relay-identity-token-secret
    docs: https://docs.solo.io/gloo-mesh-enterprise/latest/setup/prod/certs/relay/
  - name: Product license key
    type: license-key
    applies_to: feature entitlement, not request authentication
    description: >-
      A Solo-issued license key is supplied through Helm values (license.value or
      license.secretRef) or the Gloo istiod chart. Resources the license does not cover report
      ApprovalState UNLICENSED on their status rather than failing authentication.
      `meshctl license check` inspects it.
    docs: https://docs.solo.io/gloo-mesh-enterprise/latest/setup/prepare/licensing/
  - name: OIDC for the Gloo UI
    type: openIdConnect
    applies_to: the Gloo UI / dashboard
    description: >-
      The Gloo UI can be fronted by the customer's own OIDC identity provider. The issuer,
      client and callback are the customer's, which is why no OIDC discovery document is
      served on any solo.io host (see well-known/gloo-mesh-well-known.yml).
    docs: https://docs.solo.io/gloo-mesh-enterprise/latest/observability/tools/ui/auth/overview/
  - name: Docs MCP server
    type: none
    applies_to: https://search.solo.io/mcp
    description: >-
      Probed 2026-09-12: initialize and tools/list both return 200 with no credential and the
      published connection instructions state "No authentication required".
mesh_traffic_auth:
  note: >-
    Distinct from authenticating TO Gloo Mesh: these are the authN/authZ mechanisms Gloo Mesh
    CONFIGURES for the traffic it governs, expressed as CRDs and captured in crd/.
  mechanisms:
    - Workload mTLS and SPIFFE identity (RootTrustPolicy, IssuedCertificate, SpireRegistrationEntry)
    - JWT validation and claim/scope-based authorization (JWTPolicy)
    - External auth — API keys, LDAP, OIDC, OPA, multi-step (ExtAuthPolicy, ExtAuthServer, AuthConfig)
    - Request authorization between workloads (AccessPolicy)