search

plumber-cd / terraform-backend-git

Terraform HTTP Backend implementation that uses Git repository as storage
Apache License 2.0
185 stars 18 forks source link

Add options of TLS backend and Basic HTTP Authentication #12

Closed binlab closed 2 years ago

binlab commented 4 years ago

Regarding running backend remotely https://github.com/plumber-cd/terraform-backend-git#running-backend-remotely, I agree it's not so good idea at all, but for some cases, it might be very powerful (e.g. service inside a private local network for a couple of users). And basically it's not so bad as Terraform currently supports TLS encryption for HTTP backend and HTTP basic authentication with login/password https://www.terraform.io/docs/backends/types/http.html#password. A combination of TLS + Basic HTTP auth gives enough protection for small integrations. So, could you implement options TLS backend and Basic HTTP authentication for service? It also is very useful even for running on localhost (e.g. systemd) as an additional layer of security

dee-kryvenko commented 4 years ago

Ah, somehow I missed that TF does indeed support HTTP basic authentication with login/password. I even explicitly called it out in the readme lol. I can implement that, no problem.

As to the TLS, technically yes TF does support TLS encryption like any other HTTP client. If you somehow get a trusted cert for it - it'll work. I can implement the option to provide a certificate path to the listener. However I envision a "wrapper" mode to be a default and a most commonly used choice, and getting a self-signed certificate for 127.0.0.1 into trusted automatically isn't straight forward (especially not having root privileges). TF either does not seem to allow to feed it with a custom CA. Any ideas besides skip_cert_verification?

Also just out of curiosity - what's your motivation for not using wrapper mode and setting up standalone backend in a centralized fashion? I might be missing something and understanding your use case might help me prioritize different modes support better. In my mind not using wrapper mode means something you need not supported in the wrapper mode - maybe if that something gets implemented that would be less compelling to use the alternative standalone mode?

Thanks for the interest in this project.

binlab commented 4 years ago

Thanks for the fast response! You can get certificates by Let's Encrypt and assign it to IP address in a local network, this will work. If it's hard or you don't have public domain exist another method to solve this besides skip_cert_verification:

  1. Run command (or add to ~/.bashrc for permanent) 

    export SSL_CERT_FILE=/path/to/ca/certs/self-signed-ca.pem

    (this should work with Terraform)

  2. Add /path/to/ca/certs/self-signed-ca.pem to system ca-certificates storage on Linux or keychain on MacOS

But anyway even with skip cert verification encryption will happen and the password does not leak. Within the local machine, this is good enough since it’s hard to implement a MITM attack within localhost (127.0.0.1)

binlab commented 4 years ago

Relatively motivation even with the local wrapper (e.g. Systemd or Docker) for security reasons is good to use TLS + Password. But the external solution good to small teams without the need to run a wrapper. In my case, I would like to run it in a local environment behind Bastion or VPN as an option of course.

dee-kryvenko commented 4 years ago

@binlab please check this out https://github.com/plumber-cd/terraform-backend-git/releases/tag/v0.0.14 - I've added basic HTTP Auth. I will be looking into TLS encryption later, so I am leaving this issue open.

However also please check out recent additions to the readme regarding remote operations mode.

But even then, this backend is not aiming to become a standalone project. Once backends in Terraform can be pluggable gRPC components, this backend will be converted to a normal TF gRPC plugin, HTTP support will be removed, and binaries will not be distributed separately anymore (I believe TF will be able to fetch them automatically just like it does it for providers right now). Until that happens, basically HTTP protocol is used instead of gRPC, and downloading and running this backend is delegated to the user. Therefore this backend recommended to be used in plugin/wrapper notion, i.e. you start it just before running Terraform and then you stop it right after Terraform is finished, and it happens on the same host. The wrapper mode makes that very scenario even easier, it run Terraform for you so you don't have to maintain multiple console windows. At the end of the day, you are not running Terraform AWS Provider remotely, are you?

Even though the traffic can be secured with HTTP TLS encryption (WIP), and Basic HTTP Authentication can be added, authentication and encryption is there just for the sake of securing local traffic, and even when it's enabled - remote operations mode is not recommended.

Therefore it will not be considered to implement any rich HTTP-related features such as AD/Okta HTTP authentication, or any other features that will move this project further away from the goal to become a gRPC plugin.

Please let me know if that makes sense or if you have any feedback. Above is my current stance on remote mode but of course the world changes on a daily basis - I am open to suggestions.