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

Get certificate from Key Vault in kubernetes.io/tls secret type #821

Closed
antoineozenne-at-leocare opened this issue Oct 19, 2023 · 4 comments
Assignees
Labels
enhancement New feature or request Kubernetes

Comments

@antoineozenne-at-leocare

Is it possible to get a certificate from Key Vault in a kubernetes.io/tls secret type? For now, I have a PFX certificate in a Key Vault. When I reference it in the AzureAppConfigurationProvider resource, I get it in a Opaque secret type, in a binary format (base64 encoded). I would like to get my certificate in a kubernetes.io/tls secret type (in a PEM format) to be able to use it with ingress-nginx for example.

This way, I could replace all my SecretProviderClass resources by only one AzureAppConfigurationProvider to get all my configuration (configuration and secrets), for each of my applications. I find that AzureAppConfigurationProvider is more comfortable and easy to use than SecretProviderClass.

@RichardChen820
Copy link
Contributor

RichardChen820 commented Nov 3, 2023

It's a good feature enhancement we can consider to support. Currently, we only support generating keyVaultReferece type items into one single Secret with opaque type because we can't predict how many secrets would be selected by the user, and theoretically, users could do whatever they want to use the secrets in opaque type Secret.

The user case you mentioned is indeed a reasonable scenario to us, and also drives us to consider supporting even more Secret types other than it.

After doing some necessary investigation, I just give my proposal in terms of the way how to support different types of Secret here.

  1. Add a new resolveCertBasedSecret flag under secret section.

      secret:
         resolveCertBasedSecret: true
         target: 
              secretName: mysecret
    

    Since Azure KeyVault's secret client API has the capability to identify whether a keyVault secret belongs to a certificate in its back, specify this resolveCertBasedSecret flag to true can dictate the provider to generate a kuberentes.io/tls type Secret naming with the keyVaultReference item key in AppConfig, all other non-cert based secrets are stored into an opaque Secret like currently we have.

  2. We preserve a special Tag .azconfig.k8s.secret.type in AppConfig, users could override the default Secret generation behavior by specifying it in AppConfig keyVaultReference item.
    image
    We can support 'opaque', 'kubernetes.io/tls', 'kubernetes.io/ssh-auth' etc.. types in this tag. Once a keyVaultRefrence item is tagged with a certain type, the provider would generate it into a single Secret naming with the item key in AppConfig in that certain type. And for sure, users should take responsibility to ensure the secret can be parsed into certain type as they provide

@RichardChen820 RichardChen820 added the enhancement New feature or request label Nov 3, 2023
@antoineozenne-at-leocare
Copy link
Author

Thank you @RichardChen820. If I understand your proposal, it can handle several secrets and of different types in only one AzureAppConfigurationProvider resource, so it is great.

@RichardChen820
Copy link
Contributor

@antoineozenne-at-leocare It supports generating TLS type Secrets in the latest v1.3.0, please check this doc for the detail.

@RichardChen820
Copy link
Contributor

Close this issue, feel free to reactivate if you have more questions.

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

No branches or pull requests

2 participants