mirror of
https://github.com/pomerium/pomerium.git
synced 2025-05-20 04:27:19 +02:00
DOCS: Create Consolidated Troubleshooting Guide and Replace FAQ (#2797)
* replace FAQ with troubleshooting * Apply suggestions from code review Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> * clarify JWT authentication issue * elevate and clarify HSTS issue * expand Set Response Header reference section * Apply suggestions from code review Co-authored-by: cmo-pomerium <91488121+cmo-pomerium@users.noreply.github.com> * capitalize Pomerium serivice names * additional capitalization Co-authored-by: bobby <1544881+desimone@users.noreply.github.com> Co-authored-by: cmo-pomerium <91488121+cmo-pomerium@users.noreply.github.com>
This commit is contained in:
Alex Fornuto
GitHub
parent
6b592afd3e
commit
f48191fe45
13 changed files with 203 additions and 74 deletions
|
|
@ -100,7 +100,7 @@ module.exports = {
|
|||
"releases",
|
||||
"architecture",
|
||||
"background",
|
||||
"FAQ",
|
||||
"troubleshooting",
|
||||
"upgrading",
|
||||
"CHANGELOG",
|
||||
],
|
||||
|
|
|
|||
|
|
@ -70,3 +70,5 @@
|
|||
/docs/topics/tcp-support.html /docs/tcp/
|
||||
/docs/install/helm.html /docs/k8s/helm.html
|
||||
/docs/topics/kubernetes-integration.html /docs/k8s/
|
||||
|
||||
/docs/FAQ.html /docs/troubleshooting.html
|
||||
|
|
@ -1,51 +0,0 @@
|
|||
---
|
||||
title: FAQ
|
||||
lang: en-US
|
||||
meta:
|
||||
- name: keywords
|
||||
content: pomerium identity-access-proxy troubleshooting faq issues
|
||||
-
|
||||
---
|
||||
|
||||
# FAQ / Troubleshooting Guide
|
||||
|
||||
[[toc]]
|
||||
|
||||
## RPC Errors
|
||||
|
||||
### `certificate signed by unknown authority`
|
||||
|
||||
When authenticating and authorizing a user for the first time, you get the following in your Pomerium logs.
|
||||
|
||||
> ERR http-error error="401 Unauthorized: ..... rpc error: code = DeadlineExceeded desc = latest connection error: connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority...."
|
||||
|
||||
**Why**
|
||||
|
||||
This error means that the proxy is rejecting the authorize service's supplied certificate (used to establish a secure connection) because it doesn't know or trust the certificate authority that is associated with the supplied certificate. This can happen for a few reasons.
|
||||
|
||||
**Solution**
|
||||
|
||||
Ensure that the proxy service knows about, and trusts the certificate authority that signed the authorize service's certificate.
|
||||
|
||||
- Add the certificate authority directly into pomerium using the certificate authority config setting.
|
||||
- Add the certificate authority to the system's underlying trust store.
|
||||
- Replace your system / docker image certificate bundle.
|
||||
|
||||
> `COPY --from=builder /etc/ssl/certs/your-cert-bundle.crt /etc/ssl/certs/ca-certificates.crt`
|
||||
|
||||
- Finally, ensure that you aren't being man-in-the-middle'd or that some eager router isn't injecting it's own certificate along the way. Use openssl to verify that your proxy service is getting the certificate you think its getting.
|
||||
> `$openssl s_client -servername pomerium.io -connect pomerium.io:443 </dev/null | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'`
|
||||
|
||||
### `rpc error: code = DeadlineExceeded`
|
||||
|
||||
When authenticating and authorizing a user for the first time, you get the following in your Pomerium logs.
|
||||
|
||||
> {"level":"error",..."error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded","http-message":"rpc error: code = DeadlineExceeded desc = context deadline exceeded","http-code":500,"message":"http-error"}
|
||||
|
||||
**Why**
|
||||
|
||||
The proxy service is not able to create a connection with the authorization service to validate a user.
|
||||
|
||||
**Solution**
|
||||
|
||||
Usually, this is the result of either a routing issue or a configuration error. Make sure that you are using the _internally_ routable URL for authorize service. Many cloud loud balancers _not not_ yet support gRPC transposing the ingress. So while your authenticate service url will probably look like `https://authenticate.corp.example.com`, your authorizer service url will likely be more like `https://pomerium-authorize-service.default.svc.cluster.local` or `https://localhost:5443`
|
||||
1
docs/docs/img/recovery-token.png
Symbolic link
1
docs/docs/img/recovery-token.png
Symbolic link
|
|
@ -0,0 +1 @@
|
|||
../../partials/img/recovery-token.png
|
||||
|
|
@ -11,7 +11,7 @@ Pomerium is capable of creating secure connections to services like SSH, Redis,
|
|||
|
||||
1. Specify this new Route as a TCP Route by prefixing `tcp+` in the **From** field, along with a port suffix.
|
||||
|
||||
The port is not used to connect to the Pomerium proxy service from the internet; this will always be port 443 (unless otherwise defined in `config.yaml`). Rather, the port defined in **From** is part of the mapping to the individual route. In this way, you can create multiple routes that share a DNS entry, differentiated by the port to determine which route they use.
|
||||
The port is not used to connect to the Pomerium Proxy service from the internet; this will always be port 443 (unless otherwise defined in `config.yaml`). Rather, the port defined in **From** is part of the mapping to the individual route. In this way, you can create multiple routes that share a DNS entry, differentiated by the port to determine which route they use.
|
||||
|
||||
For example, suppose we have a server called `augur` running behind Pomerium that has a MySQL server and also listens for SSH connections. We can create routes for `tcp+https://augur.example.com:22` and `tcp+https://augur.example.com:3306`.
|
||||
|
||||
|
|
@ -79,7 +79,7 @@ In most cases, you only need to specify the port (ex: `:2222`), and the client w
|
|||
|
||||
(optional)
|
||||
|
||||
The Pomerium proxy service address. This is required if the **Destination URL** can't be resolved from DNS or a local `hosts` entry, or if the proxy service uses a non-standard port.
|
||||
The Pomerium Proxy service address. This is required if the **Destination URL** can't be resolved from DNS or a local `hosts` entry, or if the Proxy service uses a non-standard port.
|
||||
|
||||
#### CA File Path or CA File Text
|
||||
|
||||
|
|
|
|||
|
|
@ -43,7 +43,7 @@ routes:
|
|||
When creating TCP routes, note the following:
|
||||
|
||||
- When configuring a TCP route, any HTTP specific settings such as `regex_rewrite_pattern` or `set_request_headers` have no effect.
|
||||
- While data is encrypted from a user system to Pomerium's proxy, the underlying application protocol must also support encryption for data to be fully encrypted end-to-end. Otherwise, traffic from the Pomerium proxy service to the upstream service will be unencrypted.
|
||||
- While data is encrypted from a user system to Pomerium's proxy, the underlying application protocol must also support encryption for data to be fully encrypted end-to-end. Otherwise, traffic from the Pomerium Proxy service to the upstream service will be unencrypted.
|
||||
- The ports in `from` and `to` are independent. Users only need to know the `from` URL to connect. The `to` can be changed without end user participation.
|
||||
- The port defined in `from` does not dictate what port the tunneled traffic uses. This will always be the port defined by [`address`](/reference/readme.md#address) in your Pomerium configuration (`443` by default). The port instead differentiates multiple routes to the same hostname for different services.
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Bad actors are constantly scanning the internet for exposed SSH services. Changi
|
|||
By tunneling SSH connections through your Pomerium service:
|
||||
|
||||
- All traffic is encrypted twice (once by the Pomerium TCP connection, once by SSH itself),
|
||||
- The SSH service can remain closed to the internet, or even restricted to only accept connections from the Pomerium proxy service
|
||||
- The SSH service can remain closed to the internet, or even restricted to only accept connections from the Pomerium Proxy service
|
||||
- Authentication and authorization is managed by Pomerium, using your IdP for identity, and can be easily managed at scale.
|
||||
|
||||
## Basic Connection
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ The application interacting with Pomerium must manage the following workflow. Co
|
|||
1. The user completes the identity providers login flow.
|
||||
1. The identity provider makes a callback to pomerium's authenticate service (e.g. `authenticate.corp.domain.example`) .
|
||||
1. Pomerium's authenticate service creates a user session and redirect token, then redirects back to the managed endpoint (e.g. `verify.corp.domain.example`)
|
||||
1. Pomerium's proxy service makes a callback request to the original `pomerium_redirect_uri` with the user session as an argument.
|
||||
1. Pomerium's Proxy service makes a callback request to the original `pomerium_redirect_uri` with the user session as an argument.
|
||||
1. The script or application is responsible for handling that http callback request, and securely handling the callback session (`pomerium_jwt`) queryparam.
|
||||
1. The script or application can now make any requests as normal to the upstream application by setting the `Authorization: Pomerium ${pomerium_jwt}` header.
|
||||
|
||||
|
|
|
|||
165
docs/docs/troubleshooting.md
Normal file
165
docs/docs/troubleshooting.md
Normal file
|
|
@ -0,0 +1,165 @@
|
|||
---
|
||||
title: Troubleshooting
|
||||
description: >-
|
||||
Learn how to troubleshoot common configuration issues or work around any outstanding bugs.
|
||||
sidebarDepth: 0
|
||||
lang: en-US
|
||||
meta:
|
||||
- name: keywords
|
||||
content: pomerium troubleshooting faq frequently asked questions
|
||||
---
|
||||
|
||||
# Troubleshooting
|
||||
|
||||
This article provides troubleshooting information for various tools and features in Pomerium.
|
||||
|
||||
[[toc]]
|
||||
|
||||
## Pomerium Core
|
||||
|
||||
### HTTP Strict Transport Security (HSTS)
|
||||
|
||||
By default, Pomerium sends the [`Strict-Transport-Security`](https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) response header to the browser, which pins the certificate to our browser for one year. This is common best practice to help prevent man-in-the-middle attacks but can create issues while a new Pomerium configuration is in development.
|
||||
|
||||
When you visit an endpoint while Pomerium is using an untrusted certificate (like the self-signed bootstrap certificate or a Let's Encrypt staging certificate), that certificate may be pinned in your browser. Once Pomerium is switched to a trusted production certificate, the untrusted cert must reset in the browser.
|
||||
|
||||
While developing your Pomerium environment, consider adjusting the [`SET_RESPONSE_HEADERS`](/reference/readme.md#set-response-headers) key to remove `Strict-Transport-Security` or reduce the `max-age` value until your production certificates are in place.
|
||||
|
||||
See [this article](https://www.ssl2buy.com/wiki/how-to-clear-hsts-settings-on-chrome-firefox-and-ie-browsers) for more information on clearing HSTS for specific endpoints across common browsers.
|
||||
|
||||
### JWT Authentication
|
||||
|
||||
When securing the Pomerium Authenticate service with a certificate signed by Let's Encrypt, your upstream applications may reject the certificate when attempting to access the JWT signing key. Here's an example log line from [Grafana](/guides/grafana.md):
|
||||
|
||||
```log
|
||||
logger=context error=Get "https://authenticate.localhost.pomerium.io/.well-known/pomerium/jwks.json": x509: certificate signed by unknown authority
|
||||
```
|
||||
|
||||
This is often due to the recent expiration of the [DST Root CA X3](https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/) certificate. Many default keystores used by docker images and less-frequently updated distributions still carry this expired certificate. Even though Let's Encrypt certs are cross-signed with the [ISRG Root X1](https://letsencrypt.org/certificates/) CA certificate, some applications will still reject them.
|
||||
|
||||
To clarify; this does not mean that the upstream service is rejecting the JWT signing key. Rather, it doesn't trust the Let's Encrypt certificate used by the Authorize service for TLS, and so it will not read the JWKS file.
|
||||
|
||||
For upstream applications that can use a local signing key file, you can circumvent this issue using `curl` or `wget` to download the signing key locally (relative to the upstream service). Using Grafana again as an example:
|
||||
|
||||
1. Download the `jwks.json` file from the authenticate server:
|
||||
|
||||
::::: tabs
|
||||
:::: tab curl
|
||||
|
||||
```bash
|
||||
curl https://authenticate.localhost.pomerium.io/.well-known/pomerium/jwks.json > /etc/grafana/jwks.json
|
||||
```
|
||||
::::
|
||||
:::: tab wget
|
||||
|
||||
```bash
|
||||
wget -O /etc/grafana/jwks.json https://authenticate.localhost.pomerium.io/.well-known/pomerium/jwks.json
|
||||
```
|
||||
::::
|
||||
:::::
|
||||
|
||||
1. Edit the upstream service configuration to use the local key to verify tokens:
|
||||
|
||||
```ini
|
||||
[auth.jwt]
|
||||
enabled = true
|
||||
header_name = X-Pomerium-Jwt-Assertion
|
||||
email_claim = email
|
||||
jwk_set_file = /etc/grafana/jwks.json
|
||||
cache_ttl = 60m
|
||||
```
|
||||
|
||||
### Kubernetes Ingress Controller
|
||||
|
||||
#### View Event History
|
||||
|
||||
Pomerium Ingress Controller will add **events** to the Ingress objects as it processes them.
|
||||
|
||||
```
|
||||
kubectl describe ingress/my-ingress
|
||||
```
|
||||
|
||||
```log
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal Updated 18s pomerium-ingress updated pomerium configuration
|
||||
```
|
||||
|
||||
If an error occurs, it may be reflected in the events:
|
||||
|
||||
```log
|
||||
Events:
|
||||
Type Reason Age From Message
|
||||
---- ------ ---- ---- -------
|
||||
Normal Updated 5m53s pomerium-ingress updated pomerium configuration
|
||||
Warning UpdateError 3s pomerium-ingress upsert routes: parsing ingress: annotations: applying policy annotations: parsing policy: invalid rules in policy: unsupported conditional "maybe", only and, or, not, nor and action are allowed
|
||||
```
|
||||
|
||||
### Redirect Loop with Redis Databroker
|
||||
|
||||
When using Redis, the [shared secret](/reference/readme.md#shared-secret) is used to encrypt data in Redis itself. If you change the configured shared secret, data from Redis can no longer be decrypted. This results in errant behavior, including redirect loops when a user session cannot be retrieved from the databroker.
|
||||
|
||||
The resolution is to flush the Redis database with [`FLUSHDB`](https://redis.io/commands/flushdb) or [`FLUSHALL`](https://redis.io/commands/FLUSHALL).
|
||||
|
||||
### RPC Errors
|
||||
|
||||
#### certificate signed by unknown authority
|
||||
|
||||
When authenticating and authorizing a user for the first time, you may see the following in your Pomerium logs:
|
||||
|
||||
```log
|
||||
ERR http-error error="401 Unauthorized: ..... rpc error: code = DeadlineExceeded desc = latest connection error: connection error: desc = "transport: authentication handshake failed: x509: certificate signed by unknown authority...."
|
||||
```
|
||||
|
||||
**Why**
|
||||
|
||||
This error means that the proxy is rejecting the Authorize service's supplied certificate (used to establish a secure connection) because it doesn't know or trust the certificate authority that signed it.
|
||||
|
||||
**Solution**
|
||||
|
||||
Ensure that the Proxy service knows about and trusts the certificate authority that signed the Authorize service's certificate.
|
||||
|
||||
- Add the certificate authority directly into Pomerium using the [certificate authority](/reference/readme.md#certificate-authority) config setting.
|
||||
- Add the certificate authority to the system's underlying trust store.
|
||||
- Replace your system / docker image certificate bundle.
|
||||
|
||||
For Docker:
|
||||
|
||||
```docker
|
||||
COPY --from=builder /etc/ssl/certs/your-cert-bundle.crt /etc/ssl/certs/ca-certificates.crt
|
||||
```
|
||||
- Finally, ensure that you aren't being man-in-the-middle'd or that some eager router isn't injecting its own certificate along the way. Use openssl to verify that your Proxy service is getting the certificate you think its getting.
|
||||
|
||||
```bash
|
||||
openssl s_client -servername pomerium.io -connect pomerium.io:443 </dev/null \
|
||||
| sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p'
|
||||
```
|
||||
|
||||
#### rpc error: code = DeadlineExceeded
|
||||
|
||||
When authenticating and authorizing a user for the first time, you may get the following in your Pomerium logs.
|
||||
|
||||
```log
|
||||
{"level":"error",..."error":"rpc error: code = DeadlineExceeded desc = context deadline exceeded","http-message":"rpc error: code = DeadlineExceeded desc = context deadline exceeded","http-code":500,"message":"http-error"}
|
||||
```
|
||||
|
||||
**Why**
|
||||
|
||||
The Proxy service is not able to create a connection with the authorization service to validate a user.
|
||||
|
||||
**Solution**
|
||||
|
||||
Usually, this is the result of either a routing issue or a configuration error. Make sure that you are using the _internally_ routable URL for the Authorize service. Many cloud loud balancers _do not_ yet support gRPC transposing the ingress. So while your authenticate service url will probably look like `https://authenticate.corp.example.com`, your authorizer service url will likely be more like `https://pomerium-authorize-service.default.svc.cluster.local` or `https://localhost:5443`.
|
||||
|
||||
## Pomerium Enterprise
|
||||
|
||||
### Generate Recovery Token
|
||||
|
||||
!!!include(generate-recovery-token.md)!!!
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
### Invalid Certificates from Command Line Tools
|
||||
|
||||
When using Let's Encrypt certificates, you must use the `fullchain.pem` file, not `cert.pem` in order to include intermediate certs. Browsers like Chrome will store intermediate certs for LE but other tools (like `curl`) don't, which is why your route might look fine in a web browser, but not when curl'd or used for TCP tunneling.
|
||||
|
|
@ -237,7 +237,7 @@ To preserve 0.8.x behavior, you can use the `set_request_headers` option to expl
|
|||
|
||||
#### Tracing
|
||||
|
||||
- Jaeger tracing support is no longer end-to-end in the proxy service. We recommend updating to the Zipkin provider for proper tracing support. Jaeger will continue to work but will not have coverage in the data plane.
|
||||
- Jaeger tracing support is no longer end-to-end in the Proxy service. We recommend updating to the Zipkin provider for proper tracing support. Jaeger will continue to work but will not have coverage in the data plane.
|
||||
- Option `tracing_debug` is no longer supported. Use `tracing_sampling_rate` instead. [Details](https://www.pomerium.io/configuration/#shared-tracing-settings).
|
||||
|
||||
#### Metrics
|
||||
|
|
@ -427,7 +427,7 @@ livenessProbe:
|
|||
|
||||
### All-in-one
|
||||
|
||||
If service mode (`SERVICES`/`services`) is set to `all`, gRPC communication with the authorize service will by default occur over localhost, on port `:5443`.
|
||||
If service mode (`SERVICES`/`services`) is set to `all`, gRPC communication with the Authorize service will by default occur over localhost, on port `:5443`.
|
||||
|
||||
# Since 0.2.0
|
||||
|
||||
|
|
|
|||
|
|
@ -57,7 +57,7 @@ Log level sets the global logging level for pomerium. Only logs of the desired l
|
|||
|
||||
#### Proxy Log Level
|
||||
|
||||
Proxy log level sets the logging level for the pomerium proxy service access logs. Only logs of the desired level and above will be logged.
|
||||
Proxy log level sets the logging level for the Pomerium Proxy service access logs. Only logs of the desired level and above will be logged.
|
||||
|
||||
### Cookies
|
||||
|
||||
|
|
|
|||
|
|
@ -224,7 +224,7 @@ The name of the session cookie sent to clients.
|
|||
- Environmental Variable: `COOKIE_SECRET`
|
||||
- Config File Key: `cookie_secret`
|
||||
- Type: [base64 encoded] `string`
|
||||
- Required for proxy service
|
||||
- Required for Proxy service
|
||||
|
||||
Secret used to encrypt and sign session cookies. You can generate a random key with `head -c32 /dev/urandom | base64`.
|
||||
|
||||
|
|
@ -587,7 +587,7 @@ The Client Certificate Authority is the x509 _public-key_ used to validate [mTLS
|
|||
- Options: `debug` `info` `warn` `error`
|
||||
- Default: value of `log_level` or `debug` if both are unset
|
||||
|
||||
Proxy log level sets the logging level for the pomerium proxy service access logs. Only logs of the desired level and above will be logged.
|
||||
Proxy log level sets the logging level for the Pomerium Proxy service access logs. Only logs of the desired level and above will be logged.
|
||||
|
||||
|
||||
### Service Mode
|
||||
|
|
@ -635,7 +635,7 @@ tracing_datadog_address | `host:port` address of the Datadog Trace Agent. Defaul
|
|||
|
||||
#### Jaeger (partial)
|
||||
|
||||
**Warning** At this time, Jaeger protocol does not capture spans inside the proxy service. Please use Zipkin protocol with Jaeger for full support.
|
||||
**Warning** At this time, Jaeger protocol does not capture spans inside the Proxy service. Please use Zipkin protocol with Jaeger for full support.
|
||||
|
||||
[Jaeger](https://www.jaegertracing.io/) is a distributed tracing system released as open source by Uber Technologies. It is used for monitoring and troubleshooting microservices-based distributed systems, including:
|
||||
|
||||
|
|
@ -850,7 +850,7 @@ Authenticate Service URL is the externally accessible URL for the authenticate s
|
|||
- Required; inferred in all-in-one mode to be localhost.
|
||||
- Example: `https://pomerium-authorize-service.default.svc.cluster.local` or `https://localhost:5443`
|
||||
|
||||
Authorize Service URL is the location of the internally accessible authorize service. NOTE: Unlike authenticate, authorize has no publicly accessible http handlers so this setting is purely for gRPC communication.
|
||||
Authorize Service URL is the location of the internally accessible Authorize service. NOTE: Unlike authenticate, authorize has no publicly accessible http handlers so this setting is purely for gRPC communication.
|
||||
|
||||
If your load balancer does not support gRPC pass-through you'll need to set this value to an internally routable location (`https://pomerium-authorize-service.default.svc.cluster.local`) instead of an externally routable one (`https://authorize.corp.example.com`).
|
||||
|
||||
|
|
@ -918,10 +918,16 @@ Default Upstream Timeout is the default timeout applied to a proxied route when
|
|||
|
||||
Set Response Headers specifies a mapping of [HTTP Header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers) to be added globally to all managed routes and pomerium's authenticate service.
|
||||
|
||||
By default, conservative [secure HTTP headers](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project) are set.
|
||||
By default, conservative [secure HTTP headers](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project) are set:
|
||||
|
||||
- `max-age=31536000` instructs the browser to pin the certificate for a domain for a year. This helps prevent man-in-the-middle attacks, but can create issues when developing new environments with temporary certificates. See [Troubleshooting - HSTS](/docs/troubleshooting.md#hsts) for more information.
|
||||
- `includeSubDomains` applies these rules to subdomains, which is how individual routes are defined.
|
||||
- `preload` instructs the browser to preload the certificate from an HSTS preload service if available. This means that the certificate can be loaded from an already-trusted secure connection, and the user never needs to connect to your domain without TLS.
|
||||
|
||||
|
||||
|
||||
See [MDN Web Docs - Strict-Transport-Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) for more information.
|
||||
|
||||
:::tip
|
||||
|
||||
Several security-related headers are not set by default since doing so might break legacy sites. These include:
|
||||
|
|
@ -1727,7 +1733,7 @@ If set, enables proxying of websocket connections.
|
|||
- Required
|
||||
- Example: `https://authorize.corp.example.com`
|
||||
|
||||
Authorize Service URL is the location of the internally accessible authorize service. Multiple URLs can be specified with `authorize_service_urls`.
|
||||
Authorize Service URL is the location of the internally accessible Authorize service. Multiple URLs can be specified with `authorize_service_urls`.
|
||||
|
||||
|
||||
### Google Cloud Serverless Authentication Service Account
|
||||
|
|
|
|||
|
|
@ -266,7 +266,7 @@ settings:
|
|||
- Environmental Variable: `COOKIE_SECRET`
|
||||
- Config File Key: `cookie_secret`
|
||||
- Type: [base64 encoded] `string`
|
||||
- Required for proxy service
|
||||
- Required for Proxy service
|
||||
doc: |
|
||||
Secret used to encrypt and sign session cookies. You can generate a random key with `head -c32 /dev/urandom | base64`.
|
||||
shortdoc: |
|
||||
|
|
@ -665,9 +665,9 @@ settings:
|
|||
- Options: `debug` `info` `warn` `error`
|
||||
- Default: value of `log_level` or `debug` if both are unset
|
||||
doc: |
|
||||
Proxy log level sets the logging level for the pomerium proxy service access logs. Only logs of the desired level and above will be logged.
|
||||
Proxy log level sets the logging level for the Pomerium Proxy service access logs. Only logs of the desired level and above will be logged.
|
||||
shortdoc: |
|
||||
Log level sets the logging level for the pomerium proxy service.
|
||||
Log level sets the logging level for the Pomerium Proxy service.
|
||||
- name: "Service Mode"
|
||||
keys: ["services"]
|
||||
attributes: |
|
||||
|
|
@ -727,7 +727,7 @@ settings:
|
|||
|
||||
#### Jaeger (partial)
|
||||
|
||||
**Warning** At this time, Jaeger protocol does not capture spans inside the proxy service. Please use Zipkin protocol with Jaeger for full support.
|
||||
**Warning** At this time, Jaeger protocol does not capture spans inside the Proxy service. Please use Zipkin protocol with Jaeger for full support.
|
||||
|
||||
[Jaeger](https://www.jaegertracing.io/) is a distributed tracing system released as open source by Uber Technologies. It is used for monitoring and troubleshooting microservices-based distributed systems, including:
|
||||
|
||||
|
|
@ -971,7 +971,7 @@ settings:
|
|||
- Required; inferred in all-in-one mode to be localhost.
|
||||
- Example: `https://pomerium-authorize-service.default.svc.cluster.local` or `https://localhost:5443`
|
||||
doc: |
|
||||
Authorize Service URL is the location of the internally accessible authorize service. NOTE: Unlike authenticate, authorize has no publicly accessible http handlers so this setting is purely for gRPC communication.
|
||||
Authorize Service URL is the location of the internally accessible Authorize service. NOTE: Unlike authenticate, authorize has no publicly accessible http handlers so this setting is purely for gRPC communication.
|
||||
|
||||
If your load balancer does not support gRPC pass-through you'll need to set this value to an internally routable location (`https://pomerium-authorize-service.default.svc.cluster.local`) instead of an externally routable one (`https://authorize.corp.example.com`).
|
||||
- name: "Authorize Internal Service URL"
|
||||
|
|
@ -1043,10 +1043,16 @@ settings:
|
|||
doc: |
|
||||
Set Response Headers specifies a mapping of [HTTP Header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers) to be added globally to all managed routes and pomerium's authenticate service.
|
||||
|
||||
By default, conservative [secure HTTP headers](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project) are set.
|
||||
By default, conservative [secure HTTP headers](https://www.owasp.org/index.php/OWASP_Secure_Headers_Project) are set:
|
||||
|
||||
- `max-age=31536000` instructs the browser to pin the certificate for a domain for a year. This helps prevent man-in-the-middle attacks, but can create issues when developing new environments with temporary certificates. See [Troubleshooting - HSTS](/docs/troubleshooting.md#hsts) for more information.
|
||||
- `includeSubDomains` applies these rules to subdomains, which is how individual routes are defined.
|
||||
- `preload` instructs the browser to preload the certificate from an HSTS preload service if available. This means that the certificate can be loaded from an already-trusted secure connection, and the user never needs to connect to your domain without TLS.
|
||||
|
||||
|
||||
|
||||
See [MDN Web Docs - Strict-Transport-Security](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security) for more information.
|
||||
|
||||
:::tip
|
||||
|
||||
Several security-related headers are not set by default since doing so might break legacy sites. These include:
|
||||
|
|
@ -1883,9 +1889,9 @@ settings:
|
|||
- Required
|
||||
- Example: `https://authorize.corp.example.com`
|
||||
doc: |
|
||||
Authorize Service URL is the location of the internally accessible authorize service. Multiple URLs can be specified with `authorize_service_urls`.
|
||||
Authorize Service URL is the location of the internally accessible Authorize service. Multiple URLs can be specified with `authorize_service_urls`.
|
||||
shortdoc: |
|
||||
Authorize Service URL is the location of the internally accessible authorize service.
|
||||
Authorize Service URL is the location of the internally accessible Authorize service.
|
||||
- name: "Google Cloud Serverless Authentication Service Account"
|
||||
keys: ["google_cloud_serverless_authentication_service_account"]
|
||||
attributes: |
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue