Environment variable names for configuration

[noonessh]

Description

Documentation mentions:
The Cloud SQL Auth Proxy has support for:
Configuration with environment variables

However I can't seem to find any details on what exactly the names of environment variables should be?

Potential Solution

No response

Additional Details

No response

[enocom]

If you run ./cloud-sql-proxy --help, there's a section in the message that explains this.

See

cloud-sql-proxy/cmd/root.go

Lines 223 to 247 in 136595b

	Configuration using environment variables
	Instead of using CLI flags, the Proxy may be configured using environment
	variables. Each environment variable uses "CSQL_PROXY" as a prefix and is
	the uppercase version of the flag using underscores as word delimiters. For
	example, the --auto-iam-authn flag may be set with the environment variable
	CSQL_PROXY_AUTO_IAM_AUTHN. An invocation of the Proxy using environment
	variables would look like the following:
	CSQL_PROXY_AUTO_IAM_AUTHN=true \
	./cloud-sql-proxy my-project:us-central1:my-db-server
	In addition to CLI flags, instance connection names may also be specified
	with environment variables. If invoking the Proxy with only one instance
	connection name, use CSQL_PROXY_INSTANCE_CONNECTION_NAME. For example:
	CSQL_PROXY_INSTANCE_CONNECTION_NAME=my-project:us-central1:my-db-server \
	./cloud-sql-proxy
	If multiple instance connection names are used, add the index of the
	instance connection name as a suffix. For example:
	CSQL_PROXY_INSTANCE_CONNECTION_NAME_0=my-project:us-central1:my-db-server \
	CSQL_PROXY_INSTANCE_CONNECTION_NAME_1=my-other-project:us-central1:my-other-server \
	./cloud-sql-proxy

for the message.

[pataquets]

@enocom As far as I could find in the docs, there is no available env var for passing auth tokens when using the --auto-iam-authn switch (if it's possible, but missing in the docs, I'll be happy to send a PR).
This would be super useful, specially for Docker scenarios. It could even automatically assume --auto-iam-auth switch if present for extra convenience.

Would this be an acceptable PR to merge? (I can track this by filing a separate issue, if desired)

[enocom]

Do you mean CSQL_PROXY_AUTO_IAM_AUTHN? That is supported. Otherwise, there's not a way to manually provide OAuth2 tokens.

[pataquets]

No, not that one, which just maps to --auto-iam-authn.
I had to dig a bit in the repo to confirm that the env var mapped to that switch, as it's not in the docs (fixed by #2264).
What I'd like to pass as env vars are values for --login-token and --token switches, as they're needed when using --auto-iam-authn.

[enocom]

Does CSQL_PROXY_LOGIN_TOKEN and CSQL_PROXY_TOKEN not work? We have tests to ensure that works.

[froblesmartin]

Related to this, I have been looking at the code and docs, and to be honest, I find it a bit confusing. Looking at the GitHub Workflow tests and the .envrc.example file, I see for example for the connection name, it can be defined with a variable per type of database:

• MYSQL_CONNECTION_NAME
• POSTGRES_CONNECTION_NAME
• SQLSERVER_CONNECTION_NAME

but then, in multiple places, the environment variable mentioned is just INSTANCE_CONNECTION_NAME, for example, to be used with the common prefix: CSQL_PROXY_INSTANCE_CONNECTION_NAME.

This is just an example, but in summary, I think it would be nice to document all the different variables and configurations, which are now spread between the README.md, CLI help, and just code.

[enocom]

The best docs we have right now are in the help message -- but agreed that we should surface that better in the README.

Also, by the way, the .envrc.example is only for development of the Proxy -- not for using it.

[froblesmartin]

@hessjcg @enocom thanks for that PR #2264!

Still, I think it could be useful to have all the possible configurations documented somewhere. In the README there are many features explained with their flag, but not all. Ideally, this should be generated from the source code to avoid having to maintain duplicates.

Is there anything against using the automatic Cobra MarkDown docs generator?

If not, may I look into adding it and open a PR? 😃

[jackwotherspoon]

Still, I think it could be useful to have all the possible configurations documented somewhere. In the README there are many features explained with their flag, but not all. Ideally, this should be generated from the source code to avoid having to maintain duplicates.

This is something we have wanted to fix for a while, I agree there should be one source of truth that generates the README. We actually created an issue for tracking this work but none of us on the team have had the time to get to it yet #2064

Is there anything against using the automatic Cobra MarkDown docs generator?

I personally don't have anything against the Cobra MarkDown generator but I also don't have any experience with it personally. I will let @enocom and @hessjcg weigh in as well if they are familiar with it.

If not, may I look into adding it and open a PR? 😃

Of course! We absolutely love to take contributions from the community. That would be amazing 👏

[enocom]

@froblesmartin Have you looked at the --help option?

We're working on this same issue for AlloyDB here: GoogleCloudPlatform/alloydb-auth-proxy#709. We'll take a look at the docs generator -- that might be a nice option.

[froblesmartin]

@enocom @jackwotherspoon FYI I have opened #2336 😉