mirror of
https://github.com/pomerium/pomerium.git
synced 2025-08-04 01:09:36 +02:00
92 lines
3.8 KiB
YAML
92 lines
3.8 KiB
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"
|
|
- name: "From"
|
|
- name: "To"
|
|
- name: "Redirect"
|
|
- name: "Policies"
|
|
- name: "Pass Identity Headers"
|
|
- name: "Enable Google Cloud Serverless Authentication"
|
|
- name: "Matchers"
|
|
- name: "Rewrite"
|
|
- name: "Timeouts"
|
|
- name: "Headers"
|
|
- name: "Load Balancer"
|
|
- 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/#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.
|
|
|
|
|
|
|
|
#### Pomerium Policy Language
|
|
|
|
From the **EDITOR** tab users can write policies in Pomerium Policy Language (**PPL**), a YAML-based notation.
|
|
|
|
|
|
|
|
#### 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"
|
|
keys: ["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 -->
|
|
- 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.
|