Skip to main content

Glossary

Pomerium's documentation uses a lot of terminology specific to the networking and security space. This glossary defines common terms readers may be unfamiliar with. If you come across an unfamiliar term not listed in this page, please let us know in our Discuss support forum and we'll add it.

General​

Access Token​

This general term refers to a string that validates the holder to have a specific set of permissions, issued by an identifying service like an identity provider. Most of the access tokens discussed in our docs are JSON Web Tokens (JWTs) formatted following the Oauth 2.0 RFC.

Context-aware Proxy​

A proxy is an intermediate service between one or more clients or servers. Most of the proxies discussed in our docs are technically reverse proxies, sitting between one or more servers and all clients, providing a single point of ingress into a system.

An context-aware proxy can provide contextual access to specific services based on the identity of the client and the state of the device they are using. Using Pomerium, context is provided by the client in the form of a JWT issued by the identity provider, and optionally by the device using a secure enclave.

Identity Provider​

An identity provider (IdP) is used to authenticate a user, i.e. confirm their identity. Pomerium uses external IdPs to better integrate into existing environments and to achieve strong separation of services. Pomerium provides single sign-on from your IdP to your entire network infrastructure from a single location.

JavaScript Object Notation​

Commonly shortened to JSON, JavaScript object notation is a common format used to represent and share structured sets of data as arrays of key-value pairs.

JSON Web Key Sets​

Usually abbreviate as JWKS, this is a JSON-formatted set of one or more keys provided by a trusted issuer and used by service to verify JWTs provided by a client. Formatting is defined by the JSON Web Key RFC.

JSON Web Token​

Often referred to as JWTs, a JSON web token is a JSON-formatted string provided to a user by an identity provider, which validates the user's identity to subsequent services (such as a context-aware proxy). JWTs are formatted according to the JSON Web Token RFC

Namespace​

"Namespaces" is an over-saturated term, having different meanings in different contexts. Pomerium Enterprise uses Namespaces to provide separation of access and control to routes. Kubernetes uses their namespaces to isolate groups of resources within a cluster.

Perimeter​

The term "Perimeter" in the context of Pomerium and general networking usually refers to your internal network, and common tools like firewalls used to restrict access to it. Historically, most security models used the perimeter as the main layer of protection to a network system. The principles of zero trust assume that the perimeter can be (and likely is) compromised, and require security between each connection, including those between internal services.

Policy​

A Policy defines what services behind Pomerium a user is authorized to access based on policy criteria, such as user identity and device identity, 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 route or collection of routes.

Route​

Specific to Pomerium, a route is a defined path from outside the network (through a public domain) to an internal service. At a very basic level, a route sends traffic from external-address.company.com to internalService-address.localdomain; a route is restricted by its associated policies and encrypted by your TLS certificates.

Routes can be defined in the configuration for open-source Pomerium or the Pomerium Enterprise Console.

More advanced configurations allow identity header pass-through, path and prefix rewrites, request and response header modification, load balancer services, and other full featured ingress capabilities.

For more information, see the Routing Capabilities page.

Service Account​

A service account provides bearer token based authentication for machine-to-machine communication through Pomerium to your protected endpoints. A service account can provide authentication 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.

See the Service Accounts capabilities page for more information on how to use service accounts in Pomerium.

Single Sign-On​

Single Sign-On (SSO) is the most frequently asked for requirement by enterprise organizations looking to adopt new SaaS applications. SSO enables authentication via an organization’s identity provider, such as Google Workspace or Okta, as opposed to users or IT admins managing hundreds, if not thousands, of usernames and passwords.

Stateless​

Another overloaded term in the tech space, we use the term stateless when talking about Pomerium's Proxy, Authenticate, and Authorize components. They are stateless because they rely on the Databroker component to provide persistent data. This means that the other services can be destroyed, recreated, and scaled horizontally without any data loss.

Networking​

Custom Resource Definition​

A custom resource definition (CRD) defines a custom resource that extends the Kubernetes API to provide additional functionality specific to a custom software set. For example, cert-manager defines certificate issuers using a CRD.

East-west Traffic​

East-west traffic refers to network communication between services within an internal network, Kubernetes cluster, private cloud network, etc. This term differentiates this communication from north-south traffic.

HTTP Strict Transport Security​

Usually shortened to HSTS, this is a policy whereby a site secured with TLS provides a response header defining a period of time (usually set to a year or more) during which the browser should only access the server over TLS, and only when it provides the same certificate. This policy helps mitigate man-in-the-middle (MiTM) attacks. We suggest only defining an HSTS policy after a service has been fully configured and tested to avoid issues when switching from development to production certificates.

North-south Traffic​

North-south traffic refers to network communication from end users to services within an internal network, Kubernetes cluster, private cloud network, etc. This term differentiates this communication from east-west traffic.

Upstream / Downstream​

When discussing traffic between end users and services, we use "upstream" to refer to the services and/or service mesh that Pomerium protects & secures. Inversely, "downstream" refers to traffic between Pomerium and end users, or any other party connecting from the Internet.

Security​

Authentication​

Abbreviated as AuthN, this refers to the validation of a user's identity. It can also refer to validation of an user's device. Access to a protected resource is usually granted only after a client's authentication and authorization are validated. This is usually done by verifying the JWT provided by the client.

Authorization​

Abbreviated as AuthZ, authorization is the process of validating a client's access to a protected resource. This is usually done after a client as been authenticated, and is determined by comparing the contents of the clients JWT against the policies present for the route.

Least User Privilege​

"Least user privilege" is a core concept of the zero trust model. It's the practice of only providing a user as much access to protected systems as is required for them to operate in their job's function. This is a risk-mitigation strategy; since compromised user credentials can only be used to access services they are granted access to, users that do not need access to highly sensitive services should not have them.

Mutual Authentication​

Mutual authentication is the security strategy of having both sides of a connection validate the identity of the other. This reduces the possibility of bad actors to impersonate valid communication endpoints. This topic is discussed in detail in Mutual Authentication: A Component of Zero Trust.

Secure Enclave​

A Secure Enclave is a sub-component or device physically bound to a specific device that can safely store sensitive data used to validate device identity.

Security Keys​

Security keys are often used to provide a physical resource to perform multi-factor authentication (MFA). Common examples include Yubico's Yubikey and Google's Titan Security Key.

Trusted Execution Environment​

A TEE is a physical method of executing cryptographic functions using data that cannot be accessed by the rest of the physical device. This is a core part of device identity validation.

Zero Trust​

Zero trust is a philosophy and/or framework for security models that includes several facets. We go into detail in our Background page, but briefly: zero-trust assumes that any one method of security is fallible, and defines a set of security principles that work in concert to provide the highest security without over-burdening administrators, end users, or network devices with extraneous overhead.