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

Intent to drop tls as default #555

Closed
mmlb opened this issue Nov 10, 2021 · 5 comments
Closed

Intent to drop tls as default #555

mmlb opened this issue Nov 10, 2021 · 5 comments
Labels
kind/design Categorizes issue or PR as related to design. priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@mmlb
Copy link
Contributor

mmlb commented Nov 10, 2021

We've discussed this for a long time and generally have landed on support for dropping TLS from here (see #456). I'd like to make insecure the default and opt in for tls support. Sandbox will continue having tls support as it makes sense there, but tink-server doesn't really need it for dev purpose in its docker-compose setup. This makes local development easier and also lines up with letting a tls terminating proxy handle TLS and leave the tink connection clear and debuggable (w/o needing something like #162)

Expected Behaviour

tink-server can be started easily after go build

Current Behaviour

Need to first procure or generate tls certificates before starting tink-server.
Generic grpc debug tools need to be passed the certificates if signing keys are not in a trusted chain.
Its just a pain.

@stephen-fox
Copy link

stephen-fox commented Nov 15, 2021

I would like to propose three alternative proposals to this proposal :)

  1. Keep TLS as the default, but allow it to be disabled with a command line option along the lines of --insecure or something else that clearly conveys the intent to the operator
  2. Keep TLS as the default, but allow it to be disabled with an explicit Go build tag at compile time
  3. Create some tooling that automates the creation of a X.509 certificates and private keys for development use only, again clearly communicating the development/testing-only intent to the operator. If I understood how tink works / how it is used, perhaps this could even be used to safely to create an internal PKI

@mmlb
Copy link
Contributor Author

mmlb commented Nov 15, 2021

2 isn’t great because I’d like to use the container image, not rebuild tink.

3 is what we have already and is too much of a pain for development imo and what I’m trying to avoid doing.

1 makes sense and goes with @jacobweinstock's wishes too #456 (comment)

@Raj-Dharwadkar Raj-Dharwadkar added the kind/feature Categorizes issue or PR as related to a new feature. label Nov 16, 2021
@stephen-fox
Copy link

I should have added that Manny and I spoke about this, and decided that TLS will remain the default, but can be disabled with a as-of-yet unnamed CLI argument.

@mmlb
Copy link
Contributor Author

mmlb commented Nov 29, 2021

WIP code is up at https://github.com/mmlb/tink/tree/non-tls-by-default if anyone wants to follow along or take it up

@tstromberg tstromberg added kind/design Categorizes issue or PR as related to design. priority/backlog Higher priority than priority/awaiting-more-evidence. and removed kind/feature Categorizes issue or PR as related to a new feature. labels Nov 30, 2021
@mmlb
Copy link
Contributor Author

mmlb commented Apr 18, 2022

TLS will stay default but we no longer require it and we no longer have the wonky code that makes self-signed certs easy and the normal trusted CA based certs not-super-great, which are both what I wanted to address so this can be closed. This was fixed via #584 .

@mmlb mmlb closed this as completed Apr 18, 2022
mergify bot added a commit to tinkerbell/playground that referenced this issue Oct 25, 2022
## Description


This PR brings up the sandbox via Docker compose using the Kubernetes backend for all service. This does not completely remove the postgres backend setup but moves all the compose with postgres into an isolated directory (deploy/compose/postgres) that can be removed when we're ready. 

> I did not touch the terraform setup. I need some help validating that one. please and thank you. CC @mmlb @displague

## Why is this needed



Fixes: #142 #45 #118 #131 #133 #145 #148 
- This "fixes" a quite a few issues related to TLS cert generation. This is the case because we are not using TLS in this deployment. Also see, tinkerbell/tink#555.
- This also "fixes" any issues related to the internal registry as that is removed as the default.

## How Has This Been Tested?



Manually tested vagrant with virtualbox (on a Mac), vagrant with libvirt (on Ubuntu 22.04), and docker-compose (on on Ubuntu 22.04). 


## How are existing users impacted? What migration steps/scripts do we need?
There is no migration support. Users will need to follow a quick start guide to get started.





## Checklist:

I have:

- [x] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
ttwd80 pushed a commit to ttwd80/tinkerbell-playground that referenced this issue Sep 7, 2024
## Description


This PR brings up the sandbox via Docker compose using the Kubernetes backend for all service. This does not completely remove the postgres backend setup but moves all the compose with postgres into an isolated directory (deploy/compose/postgres) that can be removed when we're ready. 

> I did not touch the terraform setup. I need some help validating that one. please and thank you. CC @mmlb @displague

## Why is this needed



Fixes: tinkerbell#142 tinkerbell#45 tinkerbell#118 tinkerbell#131 tinkerbell#133 tinkerbell#145 tinkerbell#148 
- This "fixes" a quite a few issues related to TLS cert generation. This is the case because we are not using TLS in this deployment. Also see, tinkerbell/tink#555.
- This also "fixes" any issues related to the internal registry as that is removed as the default.

## How Has This Been Tested?



Manually tested vagrant with virtualbox (on a Mac), vagrant with libvirt (on Ubuntu 22.04), and docker-compose (on on Ubuntu 22.04). 


## How are existing users impacted? What migration steps/scripts do we need?
There is no migration support. Users will need to follow a quick start guide to get started.





## Checklist:

I have:

- [x] updated the documentation and/or roadmap (if required)
- [ ] added unit or e2e tests
- [ ] provided instructions on how to upgrade
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/design Categorizes issue or PR as related to design. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

No branches or pull requests

4 participants