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

Vault Provider Args token should not be mandatory #509

Open
arpanrec opened this issue May 13, 2024 · 6 comments
Open

Vault Provider Args token should not be mandatory #509

arpanrec opened this issue May 13, 2024 · 6 comments
Labels
awaiting/bridge The issue cannot be resolved without action in pulumi-terraform-bridge. awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). kind/bug Some behavior is incorrect or out of spec

Comments

@arpanrec
Copy link

What happened?

Vault Provider Args token should not be mandatory, as we have other authentication methods.
in node_modules/@pulumi/vault/provider.d.ts

    /**
     * Token to use to authenticate to Vault.
     */
    token: pulumi.Input<string>;

Example

const vaultSource = new vault.Provider(`vault-${resourceUniqueIdPrefix}`, {
        address: process.env.VAULT_ADDR || '',
        token: 'bug', // not needed but it's marked mandatory in the type definition
        clientAuth: {
            certFile: path.join(vaultCertDir, 'client_certificate.pem'),
            keyFile: path.join(vaultCertDir, 'client_private_key.pem'),
        },
        caCertFile: path.join(vaultCertDir, 'root_ca_certificate.pem'),
        authLogin: {
            path: 'auth/approle/login',
            parameters: {
                role_id: process.env.VAULT_APPROLE_ROLE_ID || '',
                secret_id: process.env.VAULT_APPROLE_SECRET_ID || '',
            },
        },
    });

Output of pulumi about

❯ pulumi about
CLI
Version 3.116.0
Go Version go1.22.2
Go Compiler gc

Host
OS arch
Version "rolling"
Arch x86_64

Backend
Name pulumi.com
URL https://app.pulumi.com
User Unknown
Organizations
Token type personal

Additional context

It is not mandatory in terraform vault provider.
https://registry.terraform.io/providers/hashicorp/vault/latest/docs#token

Contributing

Vote on this issue by adding a 👍 reaction.
To contribute a fix for this issue, leave a comment (and link to your pull request, if you've opened one already).

@arpanrec arpanrec added kind/bug Some behavior is incorrect or out of spec needs-triage Needs attention from the triage team labels May 13, 2024
@guineveresaenger
Copy link
Contributor

Hey @arpanrec - thank you for reporting this issue. We'll take a look as soon as we can.

@guineveresaenger guineveresaenger removed the needs-triage Needs attention from the triage team label May 14, 2024
@guineveresaenger
Copy link
Contributor

Hi @arpanrec - I took a quick peek upstream and it appears from the schema that token is in fact Required - the documentation is incorrect.

Can you tell us a bit more in which way this presents as a blocker to you? Does declaring token: '' provide a reasonable workaround?

@guineveresaenger
Copy link
Contributor

Note that I opened hashicorp/terraform-provider-vault#2237 upstream.

@arpanrec
Copy link
Author

@guineveresaenger , as you can see in the code example above I have done exactly that,
token: 'bug', and yes, it's NOT a blocker.

But I have never looked at the upstream source code of terraform-vault-provider. I just saw Terraform docs and I saw it's marked optional.

I can see you have done all the research already hashicorp/terraform-provider-vault#2237 here. Thanks

@guineveresaenger
Copy link
Contributor

@arpanrec - All right, so I've gotten some more context here.

First off, the current workaround for this issue is, as you discovered, passing an empty string to token.

Upstream has made the choice to allow for the schema to say Required but as the field has a DefaultFunc on it (this is the confusing choice), the fallback behavior is always an empty string. They've decided to document this as Optional in the documentation.

On our end, we do need to support this kind of behavior better, so I've filed pulumi/pulumi-terraform-bridge#1978 to follow up.

I'm leaving this issue open and will close when the workaround is no longer necessary. Thanks again for the find!

@guineveresaenger guineveresaenger added the blocked The issue cannot be resolved without 3rd party action. label May 15, 2024
@arpanrec
Copy link
Author

Yes, I agree, I should have checked the source code in Terraform vault provider first, as the conflict is in the source code vs terraform docs. my bad.

Off-Topic: Any way loving pulumi in big terraform to pulumi rewrite in TS. Keep it up.

@mjeffryes mjeffryes added the awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). label May 23, 2024
@mikhailshilkov mikhailshilkov added awaiting/bridge The issue cannot be resolved without action in pulumi-terraform-bridge. and removed blocked The issue cannot be resolved without 3rd party action. labels Sep 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting/bridge The issue cannot be resolved without action in pulumi-terraform-bridge. awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). kind/bug Some behavior is incorrect or out of spec
Projects
None yet
Development

No branches or pull requests

4 participants