2021-07-05 11:16:49 +08:00
|
|
|
# Put this file to one of the location, with descending priority
|
|
|
|
|
# ./security.toml
|
|
|
|
|
# $HOME/.seaweedfs/security.toml
|
|
|
|
|
# /etc/seaweedfs/security.toml
|
|
|
|
|
# this file is read by master, volume server, and filer
|
|
|
|
|
|
2023-12-21 08:21:11 +08:00
|
|
|
# comma separated origins allowed to make requests to the filer and s3 gateway.
|
|
|
|
|
# enter in this format: https://domain.com, or http://localhost:port
|
|
|
|
|
[cors.allowed_origins]
|
|
|
|
|
values = "*"
|
|
|
|
|
|
FEATURE: add JWT to HTTP endpoints of Filer and use them in S3 Client
- one JWT for reading and one for writing, analogous to how the JWT
between Master and Volume Server works
- I did not implement IP `whiteList` parameter on the filer
Additionally, because http_util.DownloadFile now sets the JWT,
the `download` command should now work when `jwt.signing.read` is
configured. By looking at the code, I think this case did not work
before.
## Docs to be adjusted after a release
Page `Amazon-S3-API`:
```
# Authentication with Filer
You can use mTLS for the gRPC connection between S3-API-Proxy and the filer, as
explained in [Security-Configuration](Security-Configuration) -
controlled by the `grpc.*` configuration in `security.toml`.
Starting with version XX, it is also possible to authenticate the HTTP
operations between the S3-API-Proxy and the Filer (especially
uploading new files). This is configured by setting
`filer_jwt.signing.key` and `filer_jwt.signing.read.key` in
`security.toml`.
With both configurations (gRPC and JWT), it is possible to have Filer
and S3 communicate in fully authenticated fashion; so Filer will reject
any unauthenticated communication.
```
Page `Security Overview`:
```
The following items are not covered, yet:
- master server http REST services
Starting with version XX, the Filer HTTP REST services can be secured
with a JWT, by setting `filer_jwt.signing.key` and
`filer_jwt.signing.read.key` in `security.toml`.
...
Before version XX: "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE. It does **not work** with the [S3 Gateway](Amazon S3 API), as this does HTTP calls to the Filer.
Starting with version XX: secured by JWT, by setting `filer_jwt.signing.key` and `filer_jwt.signing.read.key` in `security.toml`. **This now works with the [S3 Gateway](Amazon S3 API).**
...
# Securing Filer HTTP with JWT
To enable JWT-based access control for the Filer,
1. generate `security.toml` file by `weed scaffold -config=security`
2. set `filer_jwt.signing.key` to a secret string - and optionally filer_jwt.signing.read.key` as well to a secret string
3. copy the same `security.toml` file to the filers and all S3 proxies.
If `filer_jwt.signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.key`.
If `filer_jwt.signing.read.key` is configured: When sending GET or HEAD requests to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.read.key`.
The S3 API Gateway reads the above JWT keys and sends authenticated
HTTP requests to the filer.
```
Page `Security Configuration`:
```
(update scaffold file)
...
[filer_jwt.signing]
key = "blahblahblahblah"
[filer_jwt.signing.read]
key = "blahblahblahblah"
```
Resolves: #158
2021-12-30 02:47:53 +08:00
|
|
|
# this jwt signing key is read by master and volume server, and it is used for write operations:
|
|
|
|
|
# - the Master server generates the JWT, which can be used to write a certain file on a volume server
|
|
|
|
|
# - the Volume server validates the JWT on writing
|
|
|
|
|
# the jwt defaults to expire after 10 seconds.
|
2021-07-05 11:16:49 +08:00
|
|
|
[jwt.signing]
|
|
|
|
|
key = ""
|
|
|
|
|
expires_after_seconds = 10 # seconds
|
|
|
|
|
|
2021-12-24 20:59:04 +08:00
|
|
|
# by default, if the signing key above is set, the Volume UI over HTTP is disabled.
|
|
|
|
|
# by setting ui.access to true, you can re-enable the Volume UI. Despite
|
FEATURE: add JWT to HTTP endpoints of Filer and use them in S3 Client
- one JWT for reading and one for writing, analogous to how the JWT
between Master and Volume Server works
- I did not implement IP `whiteList` parameter on the filer
Additionally, because http_util.DownloadFile now sets the JWT,
the `download` command should now work when `jwt.signing.read` is
configured. By looking at the code, I think this case did not work
before.
## Docs to be adjusted after a release
Page `Amazon-S3-API`:
```
# Authentication with Filer
You can use mTLS for the gRPC connection between S3-API-Proxy and the filer, as
explained in [Security-Configuration](Security-Configuration) -
controlled by the `grpc.*` configuration in `security.toml`.
Starting with version XX, it is also possible to authenticate the HTTP
operations between the S3-API-Proxy and the Filer (especially
uploading new files). This is configured by setting
`filer_jwt.signing.key` and `filer_jwt.signing.read.key` in
`security.toml`.
With both configurations (gRPC and JWT), it is possible to have Filer
and S3 communicate in fully authenticated fashion; so Filer will reject
any unauthenticated communication.
```
Page `Security Overview`:
```
The following items are not covered, yet:
- master server http REST services
Starting with version XX, the Filer HTTP REST services can be secured
with a JWT, by setting `filer_jwt.signing.key` and
`filer_jwt.signing.read.key` in `security.toml`.
...
Before version XX: "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE. It does **not work** with the [S3 Gateway](Amazon S3 API), as this does HTTP calls to the Filer.
Starting with version XX: secured by JWT, by setting `filer_jwt.signing.key` and `filer_jwt.signing.read.key` in `security.toml`. **This now works with the [S3 Gateway](Amazon S3 API).**
...
# Securing Filer HTTP with JWT
To enable JWT-based access control for the Filer,
1. generate `security.toml` file by `weed scaffold -config=security`
2. set `filer_jwt.signing.key` to a secret string - and optionally filer_jwt.signing.read.key` as well to a secret string
3. copy the same `security.toml` file to the filers and all S3 proxies.
If `filer_jwt.signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.key`.
If `filer_jwt.signing.read.key` is configured: When sending GET or HEAD requests to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.read.key`.
The S3 API Gateway reads the above JWT keys and sends authenticated
HTTP requests to the filer.
```
Page `Security Configuration`:
```
(update scaffold file)
...
[filer_jwt.signing]
key = "blahblahblahblah"
[filer_jwt.signing.read]
key = "blahblahblahblah"
```
Resolves: #158
2021-12-30 02:47:53 +08:00
|
|
|
# some information leakage (as the UI is not authenticated), this should not
|
2021-12-24 20:59:04 +08:00
|
|
|
# pose a security risk.
|
|
|
|
|
[access]
|
|
|
|
|
ui = false
|
|
|
|
|
|
2024-02-28 00:38:55 +08:00
|
|
|
# by default the filer UI is enabled. This can be a security risk if the filer is exposed to the public
|
|
|
|
|
# and the JWT for reads is not set. If you don't want the public to have access to the objects in your
|
|
|
|
|
# storage, and you haven't set the JWT for reads it is wise to disable access to directory metadata.
|
|
|
|
|
# This disables access to the Filer UI, and will no longer return directory metadata in GET requests.
|
|
|
|
|
[filer.expose_directory_metadata]
|
|
|
|
|
enabled = true
|
|
|
|
|
|
FEATURE: add JWT to HTTP endpoints of Filer and use them in S3 Client
- one JWT for reading and one for writing, analogous to how the JWT
between Master and Volume Server works
- I did not implement IP `whiteList` parameter on the filer
Additionally, because http_util.DownloadFile now sets the JWT,
the `download` command should now work when `jwt.signing.read` is
configured. By looking at the code, I think this case did not work
before.
## Docs to be adjusted after a release
Page `Amazon-S3-API`:
```
# Authentication with Filer
You can use mTLS for the gRPC connection between S3-API-Proxy and the filer, as
explained in [Security-Configuration](Security-Configuration) -
controlled by the `grpc.*` configuration in `security.toml`.
Starting with version XX, it is also possible to authenticate the HTTP
operations between the S3-API-Proxy and the Filer (especially
uploading new files). This is configured by setting
`filer_jwt.signing.key` and `filer_jwt.signing.read.key` in
`security.toml`.
With both configurations (gRPC and JWT), it is possible to have Filer
and S3 communicate in fully authenticated fashion; so Filer will reject
any unauthenticated communication.
```
Page `Security Overview`:
```
The following items are not covered, yet:
- master server http REST services
Starting with version XX, the Filer HTTP REST services can be secured
with a JWT, by setting `filer_jwt.signing.key` and
`filer_jwt.signing.read.key` in `security.toml`.
...
Before version XX: "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE. It does **not work** with the [S3 Gateway](Amazon S3 API), as this does HTTP calls to the Filer.
Starting with version XX: secured by JWT, by setting `filer_jwt.signing.key` and `filer_jwt.signing.read.key` in `security.toml`. **This now works with the [S3 Gateway](Amazon S3 API).**
...
# Securing Filer HTTP with JWT
To enable JWT-based access control for the Filer,
1. generate `security.toml` file by `weed scaffold -config=security`
2. set `filer_jwt.signing.key` to a secret string - and optionally filer_jwt.signing.read.key` as well to a secret string
3. copy the same `security.toml` file to the filers and all S3 proxies.
If `filer_jwt.signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.key`.
If `filer_jwt.signing.read.key` is configured: When sending GET or HEAD requests to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.read.key`.
The S3 API Gateway reads the above JWT keys and sends authenticated
HTTP requests to the filer.
```
Page `Security Configuration`:
```
(update scaffold file)
...
[filer_jwt.signing]
key = "blahblahblahblah"
[filer_jwt.signing.read]
key = "blahblahblahblah"
```
Resolves: #158
2021-12-30 02:47:53 +08:00
|
|
|
# this jwt signing key is read by master and volume server, and it is used for read operations:
|
|
|
|
|
# - the Master server generates the JWT, which can be used to read a certain file on a volume server
|
|
|
|
|
# - the Volume server validates the JWT on reading
|
|
|
|
|
# NOTE: jwt for read is only supported with master+volume setup. Filer does not support this mode.
|
2021-07-05 11:16:49 +08:00
|
|
|
[jwt.signing.read]
|
|
|
|
|
key = ""
|
|
|
|
|
expires_after_seconds = 10 # seconds
|
|
|
|
|
|
FEATURE: add JWT to HTTP endpoints of Filer and use them in S3 Client
- one JWT for reading and one for writing, analogous to how the JWT
between Master and Volume Server works
- I did not implement IP `whiteList` parameter on the filer
Additionally, because http_util.DownloadFile now sets the JWT,
the `download` command should now work when `jwt.signing.read` is
configured. By looking at the code, I think this case did not work
before.
## Docs to be adjusted after a release
Page `Amazon-S3-API`:
```
# Authentication with Filer
You can use mTLS for the gRPC connection between S3-API-Proxy and the filer, as
explained in [Security-Configuration](Security-Configuration) -
controlled by the `grpc.*` configuration in `security.toml`.
Starting with version XX, it is also possible to authenticate the HTTP
operations between the S3-API-Proxy and the Filer (especially
uploading new files). This is configured by setting
`filer_jwt.signing.key` and `filer_jwt.signing.read.key` in
`security.toml`.
With both configurations (gRPC and JWT), it is possible to have Filer
and S3 communicate in fully authenticated fashion; so Filer will reject
any unauthenticated communication.
```
Page `Security Overview`:
```
The following items are not covered, yet:
- master server http REST services
Starting with version XX, the Filer HTTP REST services can be secured
with a JWT, by setting `filer_jwt.signing.key` and
`filer_jwt.signing.read.key` in `security.toml`.
...
Before version XX: "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE. It does **not work** with the [S3 Gateway](Amazon S3 API), as this does HTTP calls to the Filer.
Starting with version XX: secured by JWT, by setting `filer_jwt.signing.key` and `filer_jwt.signing.read.key` in `security.toml`. **This now works with the [S3 Gateway](Amazon S3 API).**
...
# Securing Filer HTTP with JWT
To enable JWT-based access control for the Filer,
1. generate `security.toml` file by `weed scaffold -config=security`
2. set `filer_jwt.signing.key` to a secret string - and optionally filer_jwt.signing.read.key` as well to a secret string
3. copy the same `security.toml` file to the filers and all S3 proxies.
If `filer_jwt.signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.key`.
If `filer_jwt.signing.read.key` is configured: When sending GET or HEAD requests to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.read.key`.
The S3 API Gateway reads the above JWT keys and sends authenticated
HTTP requests to the filer.
```
Page `Security Configuration`:
```
(update scaffold file)
...
[filer_jwt.signing]
key = "blahblahblahblah"
[filer_jwt.signing.read]
key = "blahblahblahblah"
```
Resolves: #158
2021-12-30 02:47:53 +08:00
|
|
|
|
|
|
|
|
# If this JWT key is configured, Filer only accepts writes over HTTP if they are signed with this JWT:
|
|
|
|
|
# - f.e. the S3 API Shim generates the JWT
|
|
|
|
|
# - the Filer server validates the JWT on writing
|
|
|
|
|
# the jwt defaults to expire after 10 seconds.
|
2022-01-01 05:05:41 +08:00
|
|
|
[jwt.filer_signing]
|
FEATURE: add JWT to HTTP endpoints of Filer and use them in S3 Client
- one JWT for reading and one for writing, analogous to how the JWT
between Master and Volume Server works
- I did not implement IP `whiteList` parameter on the filer
Additionally, because http_util.DownloadFile now sets the JWT,
the `download` command should now work when `jwt.signing.read` is
configured. By looking at the code, I think this case did not work
before.
## Docs to be adjusted after a release
Page `Amazon-S3-API`:
```
# Authentication with Filer
You can use mTLS for the gRPC connection between S3-API-Proxy and the filer, as
explained in [Security-Configuration](Security-Configuration) -
controlled by the `grpc.*` configuration in `security.toml`.
Starting with version XX, it is also possible to authenticate the HTTP
operations between the S3-API-Proxy and the Filer (especially
uploading new files). This is configured by setting
`filer_jwt.signing.key` and `filer_jwt.signing.read.key` in
`security.toml`.
With both configurations (gRPC and JWT), it is possible to have Filer
and S3 communicate in fully authenticated fashion; so Filer will reject
any unauthenticated communication.
```
Page `Security Overview`:
```
The following items are not covered, yet:
- master server http REST services
Starting with version XX, the Filer HTTP REST services can be secured
with a JWT, by setting `filer_jwt.signing.key` and
`filer_jwt.signing.read.key` in `security.toml`.
...
Before version XX: "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE. It does **not work** with the [S3 Gateway](Amazon S3 API), as this does HTTP calls to the Filer.
Starting with version XX: secured by JWT, by setting `filer_jwt.signing.key` and `filer_jwt.signing.read.key` in `security.toml`. **This now works with the [S3 Gateway](Amazon S3 API).**
...
# Securing Filer HTTP with JWT
To enable JWT-based access control for the Filer,
1. generate `security.toml` file by `weed scaffold -config=security`
2. set `filer_jwt.signing.key` to a secret string - and optionally filer_jwt.signing.read.key` as well to a secret string
3. copy the same `security.toml` file to the filers and all S3 proxies.
If `filer_jwt.signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.key`.
If `filer_jwt.signing.read.key` is configured: When sending GET or HEAD requests to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.read.key`.
The S3 API Gateway reads the above JWT keys and sends authenticated
HTTP requests to the filer.
```
Page `Security Configuration`:
```
(update scaffold file)
...
[filer_jwt.signing]
key = "blahblahblahblah"
[filer_jwt.signing.read]
key = "blahblahblahblah"
```
Resolves: #158
2021-12-30 02:47:53 +08:00
|
|
|
key = ""
|
|
|
|
|
expires_after_seconds = 10 # seconds
|
|
|
|
|
|
|
|
|
|
# If this JWT key is configured, Filer only accepts reads over HTTP if they are signed with this JWT:
|
|
|
|
|
# - f.e. the S3 API Shim generates the JWT
|
|
|
|
|
# - the Filer server validates the JWT on writing
|
|
|
|
|
# the jwt defaults to expire after 10 seconds.
|
2022-01-01 05:05:41 +08:00
|
|
|
[jwt.filer_signing.read]
|
FEATURE: add JWT to HTTP endpoints of Filer and use them in S3 Client
- one JWT for reading and one for writing, analogous to how the JWT
between Master and Volume Server works
- I did not implement IP `whiteList` parameter on the filer
Additionally, because http_util.DownloadFile now sets the JWT,
the `download` command should now work when `jwt.signing.read` is
configured. By looking at the code, I think this case did not work
before.
## Docs to be adjusted after a release
Page `Amazon-S3-API`:
```
# Authentication with Filer
You can use mTLS for the gRPC connection between S3-API-Proxy and the filer, as
explained in [Security-Configuration](Security-Configuration) -
controlled by the `grpc.*` configuration in `security.toml`.
Starting with version XX, it is also possible to authenticate the HTTP
operations between the S3-API-Proxy and the Filer (especially
uploading new files). This is configured by setting
`filer_jwt.signing.key` and `filer_jwt.signing.read.key` in
`security.toml`.
With both configurations (gRPC and JWT), it is possible to have Filer
and S3 communicate in fully authenticated fashion; so Filer will reject
any unauthenticated communication.
```
Page `Security Overview`:
```
The following items are not covered, yet:
- master server http REST services
Starting with version XX, the Filer HTTP REST services can be secured
with a JWT, by setting `filer_jwt.signing.key` and
`filer_jwt.signing.read.key` in `security.toml`.
...
Before version XX: "weed filer -disableHttp", disable http operations, only gRPC operations are allowed. This works with "weed mount" by FUSE. It does **not work** with the [S3 Gateway](Amazon S3 API), as this does HTTP calls to the Filer.
Starting with version XX: secured by JWT, by setting `filer_jwt.signing.key` and `filer_jwt.signing.read.key` in `security.toml`. **This now works with the [S3 Gateway](Amazon S3 API).**
...
# Securing Filer HTTP with JWT
To enable JWT-based access control for the Filer,
1. generate `security.toml` file by `weed scaffold -config=security`
2. set `filer_jwt.signing.key` to a secret string - and optionally filer_jwt.signing.read.key` as well to a secret string
3. copy the same `security.toml` file to the filers and all S3 proxies.
If `filer_jwt.signing.key` is configured: When sending upload/update/delete HTTP operations to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.key`.
If `filer_jwt.signing.read.key` is configured: When sending GET or HEAD requests to a filer server, the request header `Authorization` should be the JWT string (`Authorization: Bearer [JwtToken]`). The operation is authorized after the filer validates the JWT with `filer_jwt.signing.read.key`.
The S3 API Gateway reads the above JWT keys and sends authenticated
HTTP requests to the filer.
```
Page `Security Configuration`:
```
(update scaffold file)
...
[filer_jwt.signing]
key = "blahblahblahblah"
[filer_jwt.signing.read]
key = "blahblahblahblah"
```
Resolves: #158
2021-12-30 02:47:53 +08:00
|
|
|
key = ""
|
|
|
|
|
expires_after_seconds = 10 # seconds
|
|
|
|
|
|
2021-07-05 11:16:49 +08:00
|
|
|
# all grpc tls authentications are mutual
|
|
|
|
|
# the values for the following ca, cert, and key are paths to the PERM files.
|
|
|
|
|
# the host name is not checked, so the PERM files can be shared.
|
|
|
|
|
[grpc]
|
|
|
|
|
ca = ""
|
|
|
|
|
# Set wildcard domain for enable TLS authentication by common names
|
|
|
|
|
allowed_wildcard_domain = "" # .mycompany.com
|
|
|
|
|
|
|
|
|
|
[grpc.volume]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
|
|
|
|
allowed_commonNames = "" # comma-separated SSL certificate common names
|
|
|
|
|
|
|
|
|
|
[grpc.master]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
|
|
|
|
allowed_commonNames = "" # comma-separated SSL certificate common names
|
|
|
|
|
|
|
|
|
|
[grpc.filer]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
|
|
|
|
allowed_commonNames = "" # comma-separated SSL certificate common names
|
|
|
|
|
|
2022-05-15 15:43:37 +08:00
|
|
|
[grpc.s3]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
|
|
|
|
allowed_commonNames = "" # comma-separated SSL certificate common names
|
|
|
|
|
|
2021-07-05 11:16:49 +08:00
|
|
|
[grpc.msg_broker]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
|
|
|
|
allowed_commonNames = "" # comma-separated SSL certificate common names
|
|
|
|
|
|
|
|
|
|
# use this for any place needs a grpc client
|
|
|
|
|
# i.e., "weed backup|benchmark|filer.copy|filer.replicate|mount|s3|upload"
|
|
|
|
|
[grpc.client]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
2024-07-17 14:14:09 +08:00
|
|
|
|
|
|
|
|
# https client for master|volume|filer|etc connection
|
|
|
|
|
# It is necessary that the parameters [https.volume]|[https.master]|[https.filer] are set
|
2021-07-05 11:16:49 +08:00
|
|
|
[https.client]
|
|
|
|
|
enabled = true
|
2024-07-17 14:14:09 +08:00
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
|
|
|
|
ca = ""
|
2022-03-15 07:22:52 +08:00
|
|
|
|
2024-07-11 22:53:18 +08:00
|
|
|
# volume server https options
|
2021-07-05 11:16:49 +08:00
|
|
|
[https.volume]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
2022-03-15 07:22:52 +08:00
|
|
|
ca = ""
|
2021-07-05 11:16:49 +08:00
|
|
|
|
2024-07-11 22:53:18 +08:00
|
|
|
# master server https options
|
2022-03-15 07:22:52 +08:00
|
|
|
[https.master]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
|
|
|
|
ca = ""
|
2024-07-11 22:53:18 +08:00
|
|
|
|
|
|
|
|
# filer server https options
|
|
|
|
|
[https.filer]
|
|
|
|
|
cert = ""
|
|
|
|
|
key = ""
|
|
|
|
|
ca = ""
|
|
|
|
|
# disable_tls_verify_client_cert = true|false (default: false)
|