* install VuePress Plugin Tabs https://www.npmjs.com/package/vuepress-plugin-tabs * init Enterprise documentation section * replace Vuepress tab plugin now using https://github.com/superbiger/vuepress-plugin-tabs * init Enterprise Quickstart * block of enterprise doc updates * Helm Quickstart Update (#2380) * removed/fixed redundant or incorrect config And some small copy edits * Update docs/docs/quick-start/helm.md Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com> Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com> * init console with helm doc * squash me * codeblock fix * init about page * updates to Enterprise section * consolidate on Postgres * WIP helm updates * update and align OS and Enterprise helm docs * Enterprise settings docs (#2397) * init console-specific reference docs files * remove shortdoc for name * init Enterprise Reference doc * expanding Enterprise Reference * init JS script for reference subpages When reviewing please remember that I'm not a developer, be kind * update script and apply * remove errant dep * document script and expand for CLI help output * import pomerium-console_serve.yaml In future iterations, this file should be sourced at build time as an artifact from the pomerium-console repo * init new output file * update script call and output * fix anchor links * BROKEN - import content from settings.yaml when dupe is true * filtering WiP * fix dupe script, more content * replace if dupe with if not docs * squash me * squash me! * add docs about PPL (#2404) * squash meeeeee * Update docs/enterprise/install/quickstart.md Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com> * symlink img dir from docs/reference * squash mee * update install reqs * Fixed links throughout * Update docs/enterprise/install/quickstart.md Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com> * Update docs/enterprise/install/quickstart.md Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com> * remove internal note * - format python with black - format js with prettier Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com> * optimize images with imageOptim Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com> * run prettier on config.js Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com> * concepts.md Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com> * update concepts Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com> * copy edits * typo * symlink img dir from docs/reference * modify TLS section in quick-start * rm whitespace * add common links postamble * block of updates * block of updates * updates with @travisgroth * turtles all the way down * more content * import all the things * fill out reports * fill out reports * fix file extension * fix links * crosslink PPL ref * document embedded prometheus * expand example * update reqs * document non-directory users * typo fix * update metrics_address * fix broken links in example configs * update examples for route syntax * replaced required with deprecated Note that I didn't link to the route reference because I'm unsure what link formats are accepted when this file is used elsewhere. The warning block below includes a link. * update enterprise/about * Update docs/enterprise/console-settings.yaml Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * Update docs/enterprise/console-settings.yaml Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * Update docs/enterprise/concepts.md Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * Update docs/enterprise/concepts.md Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * Apply suggestions from code review Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com> * Update docs/enterprise/concepts.md Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * remove commented config lines * update non-domain user section in concepts * Update docs/enterprise/concepts.md Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * Update docs/enterprise/concepts.md Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * Update docs/enterprise/about.md Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com> * Update docs/enterprise/concepts.md Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * Update docs/enterprise/concepts.md Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * add console route to OSS conf * update enterprise settings copy from source file * Update docs/enterprise/concepts.md * Update reports reference * merge conflict resolution * update sourced doc content, fix whitespace Co-authored-by: Travis Groth <travisgroth@users.noreply.github.com> Co-authored-by: Caleb Doxsey <cdoxsey@pomerium.com> Co-authored-by: Bobby DeSimone <bobbydesimone@gmail.com> Co-authored-by: bobby <1544881+desimone@users.noreply.github.com>
9.1 KiB
title | sidebarDepth | description |
---|---|---|
Concepts | 2 | Learn how the Pomerium Enterprise Console works. |
Concepts
Namespaces
In the Pomerium Enterprise Console, a Namespace is a cornerstone organization unit. They are container objects that behave similar to a unix directory structure.
In each Namespace, administrators can create organizational units where users and groups can be added. Namespaces enable fine-grained role based access control and management. The structure and hierarchy of namespaces empower teams to self-service the routes and policies pertinent to them. Namespaces can can also be used to optionally or mandatorily inherit from their parent permission or policies.
Namespaces enable:
- Self-Service.
- Hierarchical policy enforcement (both enforced, and optional),
- Policy organization.
- RBAC for the Enterprise Console itself.
Each of these sub-concepts are related and build on each other to form a unified security model.
Self-Service Capabilities
One of the benefits of an identity-aware access proxy is that, once in place, developers and owners of enterprise applications have an incentive to configure their services to be accessible via the proxy.
Self-service has several benefits:
- Frees global administrators from continuously modifying the configuration per user requests
- Encourages service owners to own their own route configuration and policy
- Ensures a reasonable compromise between development velocity and security controls
Unlike with a VPN, or network driven access control mechanisms, application owners (with limited access permissions managed through namespaces) can maintain route and policy configuration for their own services, while higher level operations, security, and identity teams are able to enforce higher level authorization and access policies.
Hierarchical Policy Enforcement
Hierarchical policy lets administrators enforce high level authorization policy. Policies can be optional (self-select), or mandatory.
Identities and their group memberships are defined by your Identity Provider (IdP). Pomerium looks to your IdP for identity information, so policies defined using groups are always up-to-date with the access management defined upstream.
Consider this scenario: you want to enable your security team to manage high level corporate policy while enabling application owners to set finer grained user access to their specific applications. Pomerium can help you do that!
Your security team can enact top level security policies to ensure, everyone:
- has a
yourcompany.com
email account, - isn't coming from a known bad actor IP address,
From there, the security team delegates management of child Namespaces to application teams, providing flexibility to self-manage their own application Routes and Policies.
For example, a developer group can be given control to determine who has access to their Namespace, and create or edit Routes within it. They can provide authentication and authorization to their WiP app without writing new authorization code.
Meanwhile, the CFO is given manager permissions over the "Accounting" Namespace, and can set enforced or optional policies for the services within.
RBAC for Enterprise Console Users
- Namespaces are also used to achieve Role Based Access Control (RBAC) in the console itself.
- There are three different roles:
Guest (no role)
Users who are authenticated by your IdP but do not have a role assigned in the Pomerium Console can still view the list of Namespaces, but nothing else.
Viewer
A user with the Viewer role can:
- view all resources in a Namespace (Routes, Policies, Certificates), including child Namespaces
- view traffic dashboard for routes in the Namespace, including child Namespaces
- view the activity log for a namespace.
Manager
In addition to the access provided by the Viewer role, a Manager can create, read, update, and delete routes, policies, and certificates in a Namespace (as well as its children). A Manager may also reference policies and certificates in the parent Namespace.
Admin
An Admin user has permissions across all Namespaces. They can manage global settings, sessions, and service accounts, as well as view events and runtime data.
Users and Groups
Pomerium populates users and groups from your IdP. This data is cached to prevent hitting API rate-limits, ensure policy enforcement performance, and provides look-ahead support when adding users or groups to Namespaces and Policies.
Non-Domain Users
You may encounter a situation where you may want to add users that are not directly associated with your corporate identity provider service. For example, if you have a corporate GSuite account and want to add a contractor with a gmail account. In this case, there are two workarounds:
-
Create a group within your identity provider directly with the non-domain users in it. This group can be found and added to Namespaces and Policies.
-
Manually add the user's unique ID. Identify the ID from a user's Session Details page, or the Sessions page in Pomerium Enterprise Console.
A user can see their session ID by navigating to the special
/.pomerium
URL endpoint from any Pomerium managed route. The unique ID is listed as "sub" under User Claims:
Service Accounts
Service accounts provides bearer token based authentication for machine-to-machine communication through Pomerium to your protected endpoints. They can provide auth for monitoring services, create API integrations, and other non-human driven scripts or services.
A service account identity can either be based on a user entry in your IdP Directory, or exist as a custom identity managed in a Pomerium Console Namespace.
Routes
Routes define the connection pathway and configuration from the internet to your internal service. As a very basic level, a route sends traffic from external-address.company.com
to internalService-address.localdomain
, restricted by the policies associated with it, and encrypted by your TLS certificates. But more advanced configurations allow identity header pass-through, path and prefix rewrites, request and response header modification, load balancer services, and more.
Protected Endpoints
This term refers to the system or service the route provides or restricts access to.
Policies
A Policy defines who has access to what based on the identity of the user, their device, and the associated request context.
Policies can be applied to Routes directly, or enforced within a Namespace. Policies allow operators to add authorization and access control to a single, or collection of routes.
To learn more about how to create Policies in Pomerium Enterprise Console, see Reference: Policies.
Access control
Authentication and authorization are similar concepts that are often used interchangeably.
Authentication is the process of determining if you are who you say you are.
Authorization is the process of determining if you are allowed to do the thing you are trying to do.
Pomerium provides a standardized interface to add access control, regardless if an application itself has authorization or authentication baked in, so developers can focus on their app's functionality, not reinventing access control.
Authentication
Pomerium provides authentication via your existing identity provider (Pomerium supports all major single sign-on providers (Okta, G Suite, Azure, AD, Ping, Github and so on).
Authorization
Authorization policy can be expressed in a high-level, declarative language or as code that can be used to enforce ABAC, RBAC, or any other governance policy controls. Pomerium can make holistic policy and authorization decisions using external data and request context factors such as user groups, roles, time, day, location and vulnerability status.
Trust flows from identity, device-state, and context, not network location. Every device, user, and application's communication should be authenticated, authorized, and encrypted.
With Pomerium:
- requests are continuously re-evaluated on a per-request basis.
- authorization is identity and context aware; pomerium can be used to integrate data from any source into authorization policy decisions.
- trust flows from identity, device-state, and context, not network location. Every device, user, and application's communication should be authenticated, authorized, and encrypted.
- Pomerium provides detailed audit logs for all activity in your environment. Quickly detect anomalies to mitigate bad actors and revoke access with a click of a button. Simplify life-cycle management and access reviews.