pomerium/docs/enterprise/console-settings.yaml

settings:
  - name: "Reports"
    settings:
      - name: "Traffic"
      - name: "Runtime"
      - name: "Sessions"
      - name: "Events"
      - name: "Deployments"
  - name: "Manage"
    settings:
      - name: "Routes"
        doc: |
          A Route provides access to a service through Pomerium.
        settings:
          - name: "General"
            doc: |
              The **General** tab defines the route path, both from the internet and to the internal service, and the policies attached. Note that policies enforced on a Namespace the Route resides in will also be applied.
            settings:
              - name: "Name"
                doc: This value is only visible in the Console UI.
              - name: "From"
              - name: "To"
              - name: "Redirect"
              - name: "Pass Identity Headers"
              - name: "Policies"
                doc: Add or remove Policies to be applied to the Route. Note that Policies enforced in the Route's Namespace will be applied automatically.
              - name: "Enable Google Cloud Serverless Authentication"
                doc: |
                  @Travis plz explain.
          - name: "Matchers"
            settings:
              - name: Path
              - name: Prefix
              - name: Regex
          - name: "Rewrite"
            settings:
              - name: "Prefix Rewrite"
              - name: "Regex Rewrite Pattern"
                keys: ["regex_rewrite_pattern"]
                doc: |
                  The pattern to match before rewriting, ex: `^/service/([^/]+)(/.*)$`.
              - name: "Regex Rewrite Substitution"
                keys: ["regex_rewrite_substitution"]
                doc: |
                  The substitution for your regex pattern, ex: `\\2/instance/\\1`.
          - name: "Timeouts"
            settings:
              - name: "Allow Websockets"
                keys: ["allow_websockets"]
              - name: "Timeout"
                keys: ["timeout"]
              - name: "Idle Timeout"
                keys: ["idle_timeout"]
          - name: "Headers"
            settings:
              - name: "Host Headers"
                keys: ["host_rewrite"]
              - name: "Set Request Headers"
              - name: "Remove Request Headers"
              - name: "Rewrite Response Headers"
          - name: "Load Balancer"
            settings:
              - name: "Load Balancing Policy"
      - name: "Policies"
        keys: ["Policy"]
        doc: |
          A Policy defines what permissions a set of users or groups has. Policies are applied to Namespaces or Routes to associate the set of permissions with a service or set of service, completing the authentication model.

          ::: tip
          This is a separate concept from [policies](/reference/readme.md#policy) in the non-enterprise model. In open-source Pomerium, the `policy` block defines both routes and access.
          :::

          Policies can be constructed three ways:

          ### Web UI

          From the **BUILDER** tab, users can add allow or deny blocks to a policy, containing and/or/not/nor logic to allow or deny sets of users and groups.

          ![A policy being constructed in Pomerium Enterprise console allowing a single user access](../img/example-policy-single-user.png)

          ### Pomerium Policy Language

          From the **EDITOR** tab users can write policies in Pomerium Policy Language (**PPL**), a YAML-based notation.

          ![A policy as viewed from the editor tab](../img/example-policy-editor.png)

          PPL documents contain one or more rules. Each rule has a corresponding action and one or more logical operators.
          Each logical operator contains criteria and each criterion has a name and corresponding data.

          PPL documents are defined via YAML:

          ```yaml
          - allow:
              or:
                - email:
                    is: x@example.com
                - email:
                    is: y@example.com
          ```

          The available rule actions are:

          - `allow`
          - `deny`

          The available logical operators are:

          - `and`
          - `or`
          - `not`
          - `nor`

          The available criteria types are:

          - `accept`
          - `authenticated_user`
          - `claim`
          - `date`
          - `day_of_week`
          - `domain`
          - `email`
          - `groups`
          - `reject`
          - `time_of_day`
          - `user`

          Some criteria also support a sub-path as part of the criterion name:

          ```yaml
          - allow:
              or:
                - claim/family_name:
                    is: Smith
          ```

          ### Rego

          For those using [OPA](https://www.openpolicyagent.org/), the **REGO** tab will accept policies written in Rego.

          ::: tip
          A policy can only support PPL or Rego. Once one is set, the other tab is disabled.
          :::

          ### Overrides

          - **Any Authenticated User**: This setting will allow access to a route with this policy attached to any user who can authenticate to your Identity Provider (**IdP**).
          - **CORS Preflight**:
          - **Public Access**: This setting allows complete, unrestricted access to an associated route. Use this setting with caution.
      - name: "Certificates"
  - name: "Configure"
    settings:
      - name: "User Impersonation"
        doc: |
          Travis fill me with delicious data!
      - name: "Settings"
        settings:
          - name: "Global"
          - name: "Cookies"
          - name: "Timeouts"
          - name: "GRPC"
          - name: "Tracing"
          - name: "Authenticate"
          - name: "Authorize"
          - name: "Proxy"
      - name: "Service Accounts"
        doc: |
          <!-- Explain Service Accounts --> Service accounts...
      - name: "Namespaces"
        keys: ["namespace"]
        doc: |
          A Namespace is a collection of users, groups, routes, and policies that allows system administrators to organize, manage, and delegate permissions across their infrastructure.

          - Policies can be optional or enforced on a Namespace, and they can be nested to create inheritance.
          - Users or groups can be granted permission to edit access to routes within a Namespace, allowing them self-serve access to the routes critical to their work.