Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[requirement] Add a TLS certificate to the ingress resource #12

Open
cmoulliard opened this issue Jul 7, 2022 · 1 comment
Open

[requirement] Add a TLS certificate to the ingress resource #12

cmoulliard opened this issue Jul 7, 2022 · 1 comment

Comments

@cmoulliard
Copy link
Contributor

Proposition

Add a TLS certificate to the ingress resource using a generated or provided Secret containing the ca.crt, tls.crt and tls.key files

Why

When we install backstage on a k8s cluster and that we expose it as a HTTP endpoint, some exchanges are still taking place using the HTTPS protocol. If the ingress nginx is deployed, then a Fake Kubernetes Ingress Certificate is generated and will be displayed as invalid by Google Chrome.

Ideally we should generate a 'Backstage` self signed certificate (or signed by a CA authority as letsencrypt) and trust it on the platform of the browser.

What to do

Such a scenario could be achieved easily if we:

  • Install the Cert Manager (prereq) as helm dependency when property cert-manager.enabled: true
  • Create an issuer/certificate resources when certmanager is enabled to populate a secret containing the ca.crt, tls.crt and tls.key files
  • Configure the TLS section of the ingress resource to mount it

Note: Optionally if the user has created its own TLS secret, then it could be passed as parameter to the ingress values section.

WDYT ? @vinzscam @ChrisJBurns

@ChrisJBurns
Copy link
Contributor

@cmoulliard Yep, this sounds good. At the moment, I use Istio Gateway with Cert Manager and Let's Encrypt, so we don't really use the Ingress resource in the Chart. However I can see the benefit to this for other who may use it, I imagine using cert-manager is a good way to go also because of it's popularity. I would say we should tread carefully with self signed certs as normally they bring a whole level of complexity a lot of times - that being said, technically in an air-gapped network they may be preferred as otherwise the cert challenge won't be able to complete.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants