mirror of
https://github.com/bitnami/charts.git
synced 2026-04-02 23:37:20 +08:00
[bitnami/rabbitmq]: 8.8.0 - adds auth.tls.existingSecretFullChain option (#3192)
This commit is contained in:
@@ -23,4 +23,4 @@ name: rabbitmq
|
||||
sources:
|
||||
- https://github.com/bitnami/bitnami-docker-rabbitmq
|
||||
- https://www.rabbitmq.com
|
||||
version: 8.7.5
|
||||
version: 8.8.0
|
||||
|
||||
@@ -84,6 +84,7 @@ The following table lists the configurable parameters of the RabbitMQ chart and
|
||||
| `auth.tls.serverCertificate` | Server certificate content | `nil` |
|
||||
| `auth.tls.serverKey` | Server private key content | `nil` |
|
||||
| `auth.tls.existingSecret` | Existing secret with certificate content to RabbitMQ credentials | `nil` |
|
||||
|`auth.tls.existingSecretFullChain` | Whether or not the existing secret contains the full chain in the certificate (`tls.crt`). Will be used in place of `ca.cert` if `true`. | `false`|
|
||||
| `logs` | Path of the RabbitMQ server's Erlang log file | `-` |
|
||||
| `ulimitNofiles` | Max File Descriptor limit | `65536` |
|
||||
| `maxAvailableSchedulers` | RabbitMQ maximum available scheduler threads | `2` |
|
||||
@@ -353,6 +354,12 @@ auth:
|
||||
- Setting [auth.tls.failIfNoPeerCert](https://www.rabbitmq.com/ssl.html#peer-verification-configuration) to `false` allows a TLS connection if client fails to provide a certificate.
|
||||
- When setting [auth.tls.sslOptionsVerify](https://www.rabbitmq.com/ssl.html#peer-verification-configuration) to `verify_peer`, the node must perform peer verification. When set to `verify_none`, peer verification will be disabled and certificate exchange won't be performed.
|
||||
|
||||
#### TLS integration with `cert-manager` (Let's Encrypt certificates)
|
||||
|
||||
If using `cert-manager` to provision Let's Encrypt certificates, the `tls.crt` key in the generated TLS secret will contain the full certificate chain. Depending on the version of `cert-manager` in use, there can either be an empty `ca.crt` key, or none at all.
|
||||
|
||||
In order to instruct RabbitMQ to look for the CA certificate within the primary certificate, `auth.tls.existingSecretFullChain` can be set to `true`.
|
||||
|
||||
### Load Definitions
|
||||
|
||||
It is possible to [load a RabbitMQ definitions file to configure RabbitMQ](http://www.rabbitmq.com/management.html#load-definitions). Because definitions may contain RabbitMQ credentials, [store the JSON as a Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod). Within the secret's data, choose a key name that corresponds with the desired load definitions filename (i.e. `load_definition.json`) and use the JSON object as the value. For example:
|
||||
|
||||
@@ -297,7 +297,7 @@ spec:
|
||||
secret:
|
||||
secretName: {{ template "rabbitmq.secretTLSName" . }}
|
||||
items:
|
||||
- key: ca.crt
|
||||
- key: {{ ternary "tls.crt" "ca.crt" .Values.auth.tls.existingSecretFullChain }}
|
||||
path: ca_certificate.pem
|
||||
- key: tls.crt
|
||||
path: server_certificate.pem
|
||||
|
||||
@@ -81,6 +81,7 @@ auth:
|
||||
serverCertificate: |-
|
||||
serverKey: |-
|
||||
# existingSecret: name-of-existing-secret-to-rabbitmq
|
||||
existingSecretFullChain: false
|
||||
|
||||
## Value for the RABBITMQ_LOGS environment variable
|
||||
## ref: https://www.rabbitmq.com/logging.html#log-file-location
|
||||
|
||||
Reference in New Issue
Block a user