Skip to content

Add CSI driver to threat model #1106

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.

Sign up for GitHub

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

Merged
merged 4 commits into from
Sep 3, 2025
Merged

Add CSI driver to threat model #1106

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
a946c4b
Add CSI driver section
digivava Aug 26, 2025
5e28bf8
Lower-case driver, add category
digivava Sep 3, 2025
58afa8b
Close table tag
digivava Sep 3, 2025
3828c3c
Casing changes
digivava Sep 3, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 52 additions & 0 deletions docs/threat-model/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -14,6 +14,7 @@ The Operator occupies a privileged position in a Kubernetes cluster, with unencr
* Encrypt the Kubernetes etcd database at rest using a KMS provider. Kubernetes Secrets stored in etcd are [not encrypted at rest by default](https://kubernetes.io/docs/concepts/security/secrets-good-practices/).
* Use TLS negotiated by a well-secured certificate authority for all networked communication, especially for Vault and the Kubernetes API.
* Update the Operator, Vault, and other systems regularly to guard against known vulnerabilities.
* If using the Vault Secrets Operator CSI Driver, see the dedicated section below for details.

## Terminology

Expand Down Expand Up @@ -341,6 +342,7 @@ While none of this should be considered secret information, it can be sensitive
</tr>
</table>


### Threats specific to Kubernetes and Kubernetes Secrets

These threats are included because using Kubernetes Secrets is a fundamental requirement to using the Operator, but their applicability is not affected by whether or not the Secrets are maintained by the Operator. All usages of Kubernetes Secrets should consider the following in their threat model.
Expand Down Expand Up @@ -445,6 +447,56 @@ When etcd is encrypted by a KMS provider all objects are encrypted on disk, but
</tr>
</table>

### Threats specific to the Vault Secrets Operator CSI driver

The Vault Secrets Operator's Helm chart can also be used to deploy the Vault Secrets Operator CSI driver. This is an alternate approach to delivering Vault secrets to application Pods, in which a CSI driver Pod is deployed on each node in the Kubernetes cluster, and can mount ephemeral volumes containing Vault secrets directly to Pod containers.

Since the Vault Secrets Operator CSI driver does not make use of persistent storage e.g. Kubernetes Secrets, some of the concerns in the above section can be avoided, but other security aspects should be considered.

<table>
<tr>
<td>
<strong>ID</strong>
</td>
<td><strong>Threat</strong>
</td>
<td><strong>Categories</strong>
</td>
<td><strong>Description</strong>
</td>
<td><strong>Mitigation</strong>
</td>
</tr>
<tr>
<td>12
</td>
<td>An attacker with the ability to deploy a Pod onto the node may be able to access secret data if the accessControl permissions on the CSISecrets custom resource's spec are too broad.
</td>
<td>Information disclosure
</td>
<td>Regular expression pattern matching for Pod name, container name, namespace name, and service account name are used to restrict which Pods are allowed to mount the Vault secrets declared in a CSISecrets resource.
If an attacker is able to deploy Pods onto the node that match the provided pattern, those Pods could gain access to the sensitive data written to the volume.
</td>
<td>
<ul>

<li>
Write regular expressions carefully and granularly to avoid giving permissions too broadly.
</li>
<li>
Lock down permissions around the Kubernetes cluster in such a way that unauthorized users cannot deploy to it.
</li>
<li>
Prefer a matchPolicy of "all" over "any", and include a granular service account pattern, rather than pod name being the only requirement to match on.
</li>
<li>
Limit the number of Vault secrets that you give access to in an individual CSISecrets resource.
</li>
</ul>
</td>
</tr>
</table>
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would good to link out to the API reference docs, especially for the CSISecrets.spec. We can probably add that later once they are fully published.


## References

* [Vault Security Model](https://developer.hashicorp.com/vault/docs/internals/security)
Expand Down