Skip to content

chore: document kubernetes provider pushsecret type#4725

Merged
Skarlso merged 2 commits intoexternal-secrets:mainfrom
mhrabovcin:k8s-provider-secret-type
May 6, 2025
Merged

chore: document kubernetes provider pushsecret type#4725
Skarlso merged 2 commits intoexternal-secrets:mainfrom
mhrabovcin:k8s-provider-secret-type

Conversation

@mhrabovcin
Copy link
Copy Markdown
Contributor

Problem Statement

Adds the missing documentation about possibility to set the secret type with the Kubernetes provider on PushSecret.

Related Issue

Fixes #...

Proposed Changes

Docs change.

Checklist

  • I have read the contribution guidelines
  • All commits are signed with git commit --signoff
  • My changes have reasonable test coverage
  • All tests pass with make test
  • I ensured my PR is ready for review with make reviewable

@mhrabovcin mhrabovcin requested a review from a team as a code owner April 30, 2025 08:09
@mhrabovcin mhrabovcin requested a review from gusfcarvalho April 30, 2025 08:09
Signed-off-by: Martin Hrabovcin <martin.hrabovcin@nutanix.com>
@mhrabovcin mhrabovcin force-pushed the k8s-provider-secret-type branch from 6fafc78 to 0caac12 Compare April 30, 2025 08:10
@Skarlso
Copy link
Copy Markdown
Contributor

Skarlso commented May 5, 2025

@mhrabovcin Hello. 👋 so setting a secret type is a template capability that is accessible to anything that uses templates.

I'm a bit on the fence about this. For one, it helps for sure, examples are always good. But on second, this particular feature is documented already here: https://external-secrets.io/latest/guides/common-k8s-secret-types/

And many other places. Hmm.

@mhrabovcin
Copy link
Copy Markdown
Contributor Author

Hi @Skarlso thanks for the review. I haven't seen anywhere explicitly mentioned PushSecret behavior. I've seen the discussion here https://github.com/external-secrets/external-secrets/discussions/2728 where the same question was opened.

Please feel free to close this PR if you don't see this docs enhancement as a good fit. Thank you!

@Skarlso
Copy link
Copy Markdown
Contributor

Skarlso commented May 6, 2025

Hm, maybe it's fine to have an extra example. But the problem is then that this is specific to Kubernetes provider. But actually, it's available for ALL providers. :) You see what I mean? :)

@gusfcarvalho
Copy link
Copy Markdown
Member

re: the docs, I think its fine to add it. This behavior (spec.template.type) changing the type of secret it is created is IIRC only a thing for kubernetes. IIRC, this wouldn't work for other providers that also have multiple types like azure Keyvault.

Re: the bigger issue: This is a feature available on a generic API that is only for kubernetes. This is a reminder for the coming v2 work this should probably change and move to the Metadata pattern.

@mhrabovcin
Copy link
Copy Markdown
Contributor Author

I see and I am honestly not very familiar with other providers. In k8s the Secret type has a special meaning during the secret validation. I can move the docs to the common section.

Maybe there should be a note about the secret type behavior for push secrets per provider. It is quite straight forward to imagine impact of setting the secret type when ExternalSecret is created. But I could imagine that setting the secret type has different impact in different providers, some may even ignore this property.

@Skarlso Skarlso merged commit 94c1d5e into external-secrets:main May 6, 2025
2 checks passed
@sonarqubecloud
Copy link
Copy Markdown

sonarqubecloud bot commented May 6, 2025

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants