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

Format of the spec:parameters:objects string in SecretProviderClass for Azure #1120

Open
sebafo opened this issue Apr 14, 2023 · 1 comment
Labels
enhancement New feature or request

Comments

@sebafo
Copy link

sebafo commented Apr 14, 2023

The way how you need to format the string for the objects you want to read from a KeyVault is very confusing. I know that you have to provide a string because of the CRD specification, answered already here (#155)

But if I compare Azure and AWS it is easier to create a SecretProviderClass in AWS.

In AWS: https://github.com/aws/secrets-store-csi-driver-provider-aws#secretproviderclass-options

  parameters:
    objects: |
        - objectName: "MySecret"
          objectType: "secretsmanager"

In Azure:

parameters:
    objects:  |
      array:
        - |
          objectName: secret1
          objectAlias: SECRET_1  
          objectType: secret

The result is, that it is much easier to create this file (manually and especially automatically - e.g. with HCL)

In AWS:

spec = {
      provider = "aws"
      parameters = {
        objects = yamlencode([
          {
            objectName  = aws_secretsmanager_secret.sensitive.id
            objectType  = "secretsmanager"
            objectAlias = "sensitive"
          }
        ])
      }

In Azure:

spec = {
    provider = "azure"
    parameters = {
        objects = <<EOF
          array:
            - |
              objectName: ${var.ingress_cert_name}
              objectType: secret
        EOF
      }

If I want to build this even more generic, I can simply iterate through a list in the AWS way. For Azure, I need to use weird templates.

Why is it implemented that way for Azure? Can this be improved?

@sebafo sebafo added the enhancement New feature or request label Apr 14, 2023
@trondhindenes
Copy link

I couldn't agree more, the format is pretty horrendous.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants