set k3s_token output to sensitive

[netzding]

To reduce the risk of accidentally exporting sensitive data that was intended to be only internal, Terraform requires that any root module output containing sensitive data be explicitly marked as sensitive, to confirm your intent.

If you do intend to export this data, annotate the output value as sensitive by adding the following argument:
sensitive = true

[mysticaltech]

@aleksasiriski @ifeulner @M4t7e What do you folks think of this? I guess we had it sensitive before but somehow this was changed back to non sensitive.

More context:

If you attempt to use a sensitive output directly in another resource as an input parameter, Terraform will throw an error. This is because the type system now tracks sensitivity, and it prohibits using a sensitive value in a non-sensitive field.

However, you can still use sensitive outputs programmatically via workarounds:

• Passing Through a Resource: You can use sensitive outputs in the configuration of other resources as long as the place you're inserting it also understands it to be sensitive. Terraform will propagate the sensitive marking.
• Using Remote State: It is common to read sensitive outputs from remote state. Although you still can't output these directly to the console, you can use them in configurations where sensitive data is expected.
• Storing in Secret Manager/S3 Bucket: If you absolutely must transfer sensitive output, it's often better to store it securely in a Secrets Manager or encrypted S3 bucket, which can then be accessed programmatically through appropriate IAM roles.
• Environment Variables: Environment variables can sometimes be used for passing sensitive data, although this can vary in terms of security best practices.
• Local-exec provisioner: As a last resort, you could use a local-exec provisioner to execute some code that consumes the sensitive output, but be cautious, as this could lead to sensitive info leakage if not handled properly.

[mysticaltech]

@netzding My take on this is that we should let the user choose on that field being sensitve or not. Could you please create a boolean output_k3s_token_sensitive with a default value of false. And also mention it along the other variables in kube.tf.example for reference.

[ifeulner]

@aleksasiriski @ifeulner @M4t7e What do you folks think of this? I guess we had it sensitive before but somehow this was changed back to non sensitive.

There was some integration issue, yes. I think I marked it once as sensitive, but then some things break.

[netzding]

The reason why I added this is because internally random_password.k3s_token.result is already considered sensitive and therefore in the current state you cannot use the module as root module (I use terragrunt to compose several terraform modules to my infrastructure).
Terraform rightfully complains that a sensitive attribute is being passed as an non sensitive output.

As an alternative if you want to keep the k3s_token non-sensitive you should do so explicitly by wrapping it with the nonsensitive function:
value = nonsensitive(local.k3s_token)

Right now as a workaround I use the terragrunt overwrite function to overwrite the outputs.tf (For anyone who is facing the same issue)

[mysticaltech]

Thanks for clarifying @ifeulner, I wasn't clear on the matter myself. @netzding If you could create this output_k3s_token_sensitive flag, and make it use the nonsensitive function if false, it would be great. And by default let it be false.

[netzding]

The sensitive flag cannot be set conditionally based on variables:

╷
│ Error: Variables not allowed
│ 
│   on output.tf line 48, in output "k3s_token":
│   48:   sensitive   = var.output_k3s_token_sensitive
│ 
│ Variables may not be used here.
╵

╷
│ Error: Unsuitable value type
│ 
│   on output.tf line 48, in output "k3s_token":
│   48:   sensitive   = var.output_k3s_token_sensitive
│ 
│ Unsuitable value: value must be known
╵

So the proposed flag does not make sense in my opinion as I don't see a way to properly switch between both behaviours.
If it is an issue that this particular output is passed as sensitive then I'd suggest to do so explicitly with the nonsensitive() function. This way the module can be used as a root module via e.g. terragrunt.

Don't know if the integration issues can be solved somehow and what in general you opinion is whether efforts should be made in general to set this to sensitive.

[mysticaltech]

@netzding Thanks for hanging in there. We will merge this PR to mark it as sensitive and bump the version and announce potentially breaking changes on that. Hopefully it will not affect many people. This seems like the cleanest way to proceed.