gravitational/teleport-plugins

Terraform Provider should be able to communicate with a web proxy without files

programmerq opened this issue · 0 comments

When running terraform in some automated systems, such as terraform cloud, it is not always possible to load files for credentials. Since the addr can point to a teleport auth service or to a teleport proxy service, the terraform provider attempts to connect in different ways.

Given the constraint of no files to load, and an addr that is a teleport web proxy endpoint, we run into a problem.

Currently, the terraform provider provides the following combinations to configure it with credentials:

  • cert_path, key_path, root_ca_path, and addr to connect using key files.
    Requires file ❌, treats addr like auth service ❌

  • cert_base64, key_base64, root_ca_base64, and addr to connect using a base64-encoded key.
    doesn't require file ✅, treats addr like an auth service ❌

  • identity_file_path and addr to connect using identity file.
    requires file ❌, treats addr like a web proxy ✅

  • profile_name and profile_dir (both can be empty) and Teleport will try to connect using current profile from ~/.tsh
    requires file ❌, can treat addr like a web proxy ✅

It should be possible to force the terraform provider to connect with credentials not populated from a file, and also to connect to a web proxy rather than an auth endpoint. It seems like the easiest way to achieve this might be to add identity_file_base64

Currently, if one tries to use the base64 method to configure the provider, it fails with the following output:

�Terraform v1.3.4
on linux_amd64
Initializing plugins and modules...
╷
│ Error: Error connecting to Teleport!
│ 
│   with provider["terraform.releases.teleport.dev/gravitational/teleport"],
│   on main.tf line 22, in provider "teleport":
│   22: provider "teleport" {
│ 
│ all connection methods failed
│ 	
│ 	profile could not be decoded: current-profile is not set, 
│ 	failed to connect to addr teleport.example.com:443 as an auth server
│ 		context deadline exceeded: connection error: desc = "transport:
│ authentication handshake failed: x509: certificate is valid for
│ teleport.example.com, not teleport.cluster.local"
╵
Operation failed: failed running terraform plan (exit 1)�

A packet capture on the proxy side confirms that the terraform provider never attempts to connect to the web proxy as a web proxy. it instead always sets the SNI to teleport.cluster.local.

provider "teleport" {
  addr        = "teleport.redacted.net443"
  cert_base64 = "redacted"
  key_base64 = "redacted"
  root_ca_base64 = "redacted"
}