mirror of
https://github.com/gravitational/teleport
synced 2024-10-20 09:13:39 +00:00
docs: fix YAML syntax for Grafana header rewrite (#33604)
These are strings, not objects, so they must be quoted. Also removed the <Var> component here since it makes it harder to spot the trailing slash and breaks YAML syntax highlighting. Closes #32460
This commit is contained in:
parent
3ffeaf361a
commit
1e917f3a1b
|
@ -18,23 +18,23 @@ types of attacks. However, the checks can also block legitimate requests under c
|
|||
|
||||
### Symptom
|
||||
|
||||
If your browser can't create a secure cookie or can't authorize your login from a previously-created secure
|
||||
If your browser can't create a secure cookie or can't authorize your login from a previously-created secure
|
||||
cookie, you might see the following error:
|
||||
|
||||
**Invalid or missing CSRF token**
|
||||
|
||||
This error can be caused by ad-blocking or script-blocking extensions or by the browser itself.
|
||||
For access to applications through Teleport, you might see this error with most often with
|
||||
applications—like Grafana and ArgoCD—that use WebSockets extensively and in browsers where
|
||||
For access to applications through Teleport, you might see this error with most often with
|
||||
applications—like Grafana and ArgoCD—that use WebSockets extensively and in browsers where
|
||||
cross-site scripting restrictions require traffic to be explicitly allowed.
|
||||
|
||||
Issues with Cross-Site Request Forgery (CSRF) or Cross-Origin Resource Sharing (CORS) usually
|
||||
result in a loss of application functionality, errors in the application itself indicating that
|
||||
traffic isn't being permitted, or application logs that indicate CORS or CSRF errors.
|
||||
Issues with Cross-Site Request Forgery (CSRF) or Cross-Origin Resource Sharing (CORS) usually
|
||||
result in a loss of application functionality, errors in the application itself indicating that
|
||||
traffic isn't being permitted, or application logs that indicate CORS or CSRF errors.
|
||||
|
||||
### Solution
|
||||
|
||||
In most cases, you can fix these types of issues by adding explicit `rewrite` settings for the Origin and Host headers
|
||||
In most cases, you can fix these types of issues by adding explicit `rewrite` settings for the Origin and Host headers
|
||||
in the Teleport configuration file for each application.
|
||||
|
||||
To fix CSRF or CORS issues:
|
||||
|
@ -43,33 +43,33 @@ To fix CSRF or CORS issues:
|
|||
|
||||
1. Add a `rewrite.headers` section similar to the following `grafana` example:
|
||||
|
||||
```code
|
||||
```yaml
|
||||
app_service:
|
||||
enabled: true
|
||||
apps:
|
||||
- name: grafana
|
||||
uri: http://localhost:3000
|
||||
public_addr: <Var name="grafana.teleport.example.com"/>
|
||||
public_addr: grafana.teleport.example.com
|
||||
rewrite:
|
||||
headers:
|
||||
- Origin: <Var name="https://grafana.teleport.example.com" /> # Teleport application subdomain prepended with "https://"
|
||||
- Host: <Var name="grafana.teleport.example.com" /> # Teleport application subdomain itself
|
||||
- "Origin: https://grafana.teleport.example.com" # Teleport application subdomain prepended with "https://"
|
||||
- "Host: grafana.teleport.example.com" # Teleport application subdomain itself
|
||||
```
|
||||
|
||||
1. Save your changes and restart the Teleport service.
|
||||
|
||||
To fix CSRF or CORS issues if you deploy applications using Kubernetes and `teleport-kube-agent`:
|
||||
|
||||
1. Open the `teleport/examples/chart/teleport-kube-agent/values.yaml` file that contains the application
|
||||
1. Open the `teleport/examples/chart/teleport-kube-agent/values.yaml` file that contains the application
|
||||
configuration in a text editor.
|
||||
|
||||
1. Locate the `apps` section in the `values.yaml` file.
|
||||
|
||||
|
||||
```yaml
|
||||
# Details of at least one app to be proxied. Example:
|
||||
# apps:
|
||||
# - name: grafana
|
||||
# uri: http://localhost:3000
|
||||
# Details of at least one app to be proxied. Example:
|
||||
# apps:
|
||||
# - name: grafana
|
||||
# uri: http://localhost:3000
|
||||
apps: []
|
||||
```
|
||||
|
||||
|
@ -81,21 +81,21 @@ To fix CSRF or CORS issues if you deploy applications using Kubernetes and `tele
|
|||
apps:
|
||||
- name: grafana
|
||||
uri: http://localhost:3000
|
||||
public_addr: <Var name="grafana.teleport.example.com"/>
|
||||
public_addr: grafana.teleport.example.com
|
||||
rewrite:
|
||||
headers:
|
||||
- Origin: <Var name="https://grafana.teleport.example.com" /> # Teleport application subdomain prepended with "https://"
|
||||
- Host: <Var name="grafana.teleport.example.com" /> # Teleport application subdomain itself
|
||||
- "Origin: https://grafana.teleport.example.com" # Teleport application subdomain prepended with "https://"
|
||||
- "Host: grafana.teleport.example.com" # Teleport application subdomain itself
|
||||
```
|
||||
|
||||
## Untrusted certificate errors
|
||||
|
||||
By default, the certificates presented by the Teleport Proxy Service must be trusted and issued by
|
||||
a recognized certificate authority.
|
||||
a recognized certificate authority.
|
||||
|
||||
### Symptom
|
||||
|
||||
If you have created self-signed certificates or use certificates signed by an unrecognized
|
||||
If you have created self-signed certificates or use certificates signed by an unrecognized
|
||||
certificate authority, you might see an error similar to the following:
|
||||
|
||||
```text
|
||||
|
@ -111,7 +111,7 @@ ERROR: "unable to verify HTTPS certificate chain in : \x1b[31mERROR: \x1b[0mWARN
|
|||
|
||||
If you have properly created a root certificate authority and a self-signed
|
||||
certificate, you can use the `--insecure` command-line option to allow clients
|
||||
to accept the certificate. For example, you can start Teleport with a self-signed
|
||||
to accept the certificate. For example, you can start Teleport with a self-signed
|
||||
certificate by running a command similar to the following:
|
||||
|
||||
```code
|
||||
|
@ -120,7 +120,7 @@ sudo teleport start --config=/etc/teleport.yaml --insecure
|
|||
|
||||
If you have your own certificate authority that you would like to use to
|
||||
validate the certificate chain presented by the Teleport Proxy Service, you can
|
||||
manually set the `SSL_CERT_FILE` or `SSL_CERT_DIR` environment variable on the
|
||||
manually set the `SSL_CERT_FILE` or `SSL_CERT_DIR` environment variable on the
|
||||
command line. For example:
|
||||
|
||||
```code
|
||||
|
|
Loading…
Reference in a new issue