10 Commits

Author SHA1 Message Date
Eric Shen
b5ff00b16b
feat(tls): support ca type issuer and v1alpha* version cert-manager api (#561) 2024-12-18 07:11:54 -08:00
Duncan Schulze
0031827761
Support using self generated certificates (#523)
* Support using self generated certificates

* chore: fix linting
2024-08-23 17:49:36 +03:00
Stepan Mazurov
1bcf255e12
feat(certs): use actual v1 spec for certs (#233)
Co-authored-by: Stepan Mazurov <smazurov@quantummetric.com>

### Motivation

In #204, api version of the cert resources was updated to v1. This was insufficient because `v1` has different spec from `v1alpha1` 

This MR finishes the work that #204 and @lhotari started.

### Modifications

Changed the spec of certs to match v1 cert manager spec.

### Verifying this change

- [ ] Make sure that the change passes the CI checks.
2022-10-18 15:40:43 -05:00
Yong Zhang
0816ac2dfd
Reduce the TLS common name length (#115)
---

*Motivation*

Reduce the TLS command name to avoid getting a too long name
that could not generate a certificate.
2021-04-23 12:43:44 +08:00
Jean Helou
ba356e5df7
makes cert-manager apiVersion configurable (#107)
This commit let's users override the apiVersion referenced in this
chart so that the chart can be used with newer cert-manager releases.
(script/cert-manager/install-cert-manager.sh installs 0.13.0 when
current version is 1.2.0...)

Fixes #68

### Motivation

cert-manager apiVersion changed after cert-manager 1.0.0 was released, which prevents the chart from provisionning certificates with newer cert-manager installation because of an incompatible apiVersion.

I have a cluster with cert-manager >1.0.0 installed, making `apiVersion` overridable makes it easy for me to install pulsar on that cluster

### Modifications

I introduced the value `certs.internal_issuer.apiVersion`, which by default uses the apiVersion that was previously hardcoded (`cert-manager.io/v1alpha2`) 
I replaced all occurrences of that apiVersion by a reference to the value so that users can override it to `cert-manager.io/v1` if they have a newer version of cert-manager installed.

### Verifying this change

- [x] Make sure that the change passes the CI checks.
2021-03-16 00:44:38 -07:00
Miecio
b24ba1adf5
Fix namespace handling and missing dnsNames (#99)
Fixes for wrong namespace handling in some RBAC and missing dnsNames for TLS

### Motivation

Fixes old unused handling of namespace name in RBAC for autorecovery and bookkeeper.
Fixes Helm exception of missing key when not defining TLS dnsNames

### Modifications

Use namespace template in RBAC definitions for bookkeeper and autorecovery. Add if around every `toYaml .Values.tls.bookie.dnsNames` clause in TLS certs definitions.

### Verifying this change

- [x] Make sure that the change passes the CI checks.
2021-01-30 09:27:18 -08:00
Peter Tinti
6fbda8052c
Allows appending dnsNames to self-signed certs (#74)
Co-authored-by: Sijie Guo <sijie@apache.org>

Fixes inability to validate self-signed certs from external clients

### Motivation

Currently self-signed certificates can only be used inside of the same cluster as they are labeled with internal dns names without the possibility of appending additional values. Some use-cases require the connection of external clients. This PR aims to allow users add additional dnsNames (IP or domain) to the self-signed certificates.

### Modifications

* Adds the ability to add `dnsNames` to self-signed certificates to any component like so:

```yaml
tls:
  enabled: true
  proxy:
    enabled: true
    dnsNames:
      - test.example.com

```

### Verifying this change

- [x] Make sure that the change passes the CI checks.
2020-12-12 16:34:35 +08:00
Jean Helou
6c9856a1af
Use .Release.Namespace by default to handle namespaces (#80)
It remains possible to override the current release namespace by setting
the `namespace` value though this may lead to having the helm metadata
and the pulsar components in different namespaces

Fixes #66

### Motivation

Trying to deploy the chart in a namespace using the usual helm pattern fails for example
```
kubectl create ns pulsartest
helm upgrade --install pulsar -n pulsartest apache/pulsar
Error: namespaces "pulsar" not found
```
fixing that while keeping the helm metadata and the deployed objects in the same namespace requires declaring the namespace twice 
```
kubectl create ns pulsartest
helm upgrade --install pulsar -n pulsartest apache/pulsar --set namespace=pulsartest
Error: namespaces "pulsar" not found
```
This is needlessly confusing for newcomers who follow the helm documentation and is contrary to helm best practices.

### Modifications

I changed the chart to use the context namespace `.Release.Namespace` by default while preserving the ability to override that by explicitly providing a namespace on the commande line, with the this modification both  examples behave as expected
 
### Verifying this change

- [x] Make sure that the change passes the CI checks.
2020-12-03 19:32:05 -08:00
Elad Dolev
5049d3564a
add support for multiple clusters (#60)
Co-authored-by: Elad Dolev <elad@firebolt.io>

### Motivation

Give the ability to deploy multi-cluster instance on K8s clusters with non-default `clusterDomain`, and connect to external configuration-store

### Modifications

- give the ability to change cluster's name
- give the ability to change `clusterDomain`
- fix external configuration store functionality
- use broker ports variables
- use label templates, and add `component` label in several places

### Verifying this change

- [x] Make sure that the change passes the CI checks.
2020-09-08 10:06:30 +08:00
Sijie Guo
0338d17b89
Publish chart index to gh-pages branch (#3)
*Motivation*

Release helm chart when new tags are created
2020-04-21 02:44:58 -07:00