-
Notifications
You must be signed in to change notification settings - Fork 47
VSO CSI driver documentation #691
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
base: main
Are you sure you want to change the base?
Conversation
Vercel Previews Deployed
|
@@ -301,7 +301,7 @@ In any trusted broker situation, the broker (in this case, the Jenkins worker) m | |||
Also, as the Vault audit logs provide time-stamped events, monitor the whole process with alerts on two events: | |||
|
|||
- When a wrapped SecretID is requested for an AppRole, and no Jenkins job is running | |||
- When the Jenkins slave attempts to unwrap the token and Vault refuses as the token has already been used | |||
- When the Jenkins agent attempts to unwrap the token and Vault refuses as the token has already been used |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an unrelated thing I caught
Broken Link CheckerSummary
Errors per inputErrors in content/vault/v1.20.x/content/docs/deploy/kubernetes/vso/helm.mdx
|
@@ -39,6 +40,8 @@ Use these links to navigate to a particular top-level stanza. | |||
|
|||
- `replicas` ((#v-controller-replicas)) (`integer: 1`) - Set the number of replicas for the operator. | |||
|
|||
- `priorityClassName` ((#v-controller-priorityclassname)) (`string: ""`) - Set the priority class for the operator. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
priorityClassName
, topologySpreadConstraints
, and podDisruptionBudget
are not part of this work, but they got auto-generated along with the rest of this because it looks like docs generation got missed last time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain how you generated the content? If it's auto-generated somehow, EDU should be editing the content at the source instead of trying to edit the docs afterward.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The Helm docs are generated by the make gen-helm-docs
command in the vault-secrets-operator repo. (Well, this particular iteration is from a private fork of that repo, but that's typically where the generation is done.)
Is the Education team typically added as a codeowner for field descriptions in the main Vault repo, like wherever the Vault CLI help text lives, for example? I would say this is similar to that -- the descriptions of each field lives with the fields themselves, but we have a helper script that gathers them up and spits it out in this format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally I think it will impact velocity if we need to wait for an Education approver for any PR that updates the available fields in VSO (our API, essentially). Happy to change any descriptions of those fields that are inaccurate or unclear though, when you review the docs in this repo.
content/vault/v1.20.x/content/docs/deploy/kubernetes/csi/index.mdx
Outdated
Show resolved
Hide resolved
|
||
The Vault CSI Provider allows pods to consume Vault secrets using | ||
[CSI Secrets Store](https://github.com/kubernetes-sigs/secrets-store-csi-driver) volumes. | ||
[Secrets Store CSI](https://github.com/kubernetes-sigs/secrets-store-csi-driver) volumes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Secrets Store CSI](https://github.com/kubernetes-sigs/secrets-store-csi-driver) volumes. | |
[Secrets Store CSI](https://github.com/kubernetes-sigs/secrets-store-csi-driver) | |
volumes. You can deploy the | |
[HashiCorp CSI driver](/vault/docs/platform/k8s/vso/vso-csi) as part of your | |
Vault Secrets Operator instance. |
~> For HashiCorp's CSI driver which can be deployed as part of the Vault Secrets Operator, | ||
see the documentation for the [Vault Secrets Operator CSI driver](/vault/docs/platform/k8s/vso/vso-csi). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
~> For HashiCorp's CSI driver which can be deployed as part of the Vault Secrets Operator, | |
see the documentation for the [Vault Secrets Operator CSI driver](/vault/docs/platform/k8s/vso/vso-csi). |
There's no need to make this a separate alert. We can fold it into the introduction
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I should have probably provided this information to you in advance, but the Vault Secrets Operator CSI Driver is actually a new, different offering from the Vault CSI Provider.
In light of that, to reduce confusion, we've decided to rename the Vault CSI Provider "Secrets Store CSI Provider for Vault".
So:
- Vault Secrets Operator CSI Driver -- the new offering that all my changes in the
vso
folder are related to - Secrets Store CSI Provider for Vault -- the older offering, which is part of a non-HashiCorp solution called "Secrets Store CSI" that we essentially just built an extension for. All the changes in the
csi
folder are just me renaming that thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reading that, do you think it makes sense to keep it as an alert (like "hey! you might want this other cool thing instead! y'know, our thing!!") rather than as part of the introduction to the Secrets Store CSI offering?
Or is this perhaps what the <Tip>
thing is for?
content/vault/v1.20.x/content/docs/deploy/kubernetes/vso/index.mdx
Outdated
Show resolved
Hide resolved
content/vault/v1.20.x/content/docs/deploy/kubernetes/vso/installation.mdx
Outdated
Show resolved
Hide resolved
content/vault/v1.20.x/content/docs/deploy/kubernetes/vso/installation.mdx
Outdated
Show resolved
Hide resolved
content/vault/v1.20.x/content/docs/deploy/kubernetes/vso/installation.mdx
Outdated
Show resolved
Hide resolved
content/vault/v1.20.x/content/docs/deploy/kubernetes/vso/vso-csi.mdx
Outdated
Show resolved
Hide resolved
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@benashz Can you please verify that these comparisons are factually correct? Especially Vault Agent Injector and Secrets Store CSI Provider for Vault which I am less familiar with.
This PR contains documentation for a new feature being added to the VSO Helm chart, a HashiCorp-maintained "CSI driver".
(Do not merge until:
I also updated other relevant pages to link to it for easier discoverability.