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

Use string concatenation (+) on secrets #1514

Open
djryanj opened this issue Aug 20, 2024 · 5 comments · May be fixed by #2841
Open

Use string concatenation (+) on secrets #1514

djryanj opened this issue Aug 20, 2024 · 5 comments · May be fixed by #2841
Assignees
Labels
enhancement New feature or request proposal A proposal for new functionality.

Comments

@djryanj
Copy link

djryanj commented Aug 20, 2024

Request

Currently, it doesn't seem possible to use an operator like + (which works for strings) on secret types. It would be good if that kind of thing was available.

Use case

For example, constructing a connection_string in a prometheus.exporter.mssql component:

remote.kubernetes.secret "sql" {
  namespace = "alloy"
  name = "sql-password"
}

prometheus.exporter.mssql "demo" {
  connection_string = "sqlserver://grafana-alloy:" + remote.kubernetes.secret.sql.data.pwd + "@mssql:1433?trustservercertificate=true"
}

The majority of the connection_string isn't actually secret, even if the result is, but doing the above results in an error like:

Error: /etc/alloy/config.alloy:32:58: remote.kubernetes.secret.sql.data.pwd should be one of [number string] for binop +, got capsule
31 | prometheus.exporter.mssql "demo" {
32 |   connection_string = "sqlserver://grafana-alloy:" + remote.kubernetes.secret.sql.data.pwd + "@mssql:1433?trustservercertificate=true"
   |      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
33 | }

Marking the export as nonsensitive works:

prometheus.exporter.mssql "demo" {
  connection_string = "sqlserver://grafana-alloy:" + nonsensitive(remote.kubernetes.secret.sql.data.pwd) + "@mssql:1433?trustservercertificate=true"
}

But that exposes the secret in logs.

Alternatives:

  1. A way to "un-capsule" the secret somehow but keep it secret;
  2. For the mssql (and the like) component to understand that capsule somehow (e.g., maybe the username and password fields can be provided separately from the rest of the connection string, and the string constructed internally);
  3. Better documentation on how to do the above with existing functionality

Thanks in advance.

@djryanj djryanj added the enhancement New feature or request label Aug 20, 2024
@wildum wildum added the proposal A proposal for new functionality. label Aug 28, 2024
@wildum
Copy link
Contributor

wildum commented Aug 28, 2024

Thanks for opening a ticket, that seems reasonable to me.
I would suggest the following for concatenation:

  • secret + string = secret
  • secret + secret = secret

@wildum wildum moved this from Incoming to Active in Alloy proposals Dec 9, 2024
@dehaansa
Copy link
Contributor

dehaansa commented Dec 9, 2024

I think a good solution should also support use of string functions on a secret where appropriate
string.trim_space(<secret>) = secret

@benoitschipper
Copy link

Hey all, just wanted to Subscribe and also share that I had the same experience.
Wanted to obscure the X-Scope-OrgId from internal public git repo's. the nonsensitive was the only option that worked as the header field expected a string and was unable to deal with a secret.

    loki.write "CPET_LOKI_OPENSOURCE" {
      endpoint {
        url = remote.kubernetes.configmap.endpoints.data["opensourcelogsendpoint"]
        
        headers = {
          "X-Scope-OrgID" = nonsensitive(remote.kubernetes.secret.opensource.data["dev"]),
        }

        tls_config {
            ca_file = "/etc/example-cabundle/ca-bundle.crt"
        }
      }
    }

Also agree with your suggestions 👍

@wildum wildum moved this from Active to Accepted in Alloy proposals Jan 20, 2025
@ravishankar15
Copy link
Contributor

ravishankar15 commented Feb 25, 2025

I would like to add this implementation to alloy. If work is not been started on this can we assign this to me.

@wildum
Copy link
Contributor

wildum commented Feb 25, 2025

done, thanks!

@ravishankar15 ravishankar15 linked a pull request Feb 26, 2025 that will close this issue
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request proposal A proposal for new functionality.
Projects
Status: Accepted
Development

Successfully merging a pull request may close this issue.

5 participants