-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Add proposal for mount options #321
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
# Mount options for mountable volume types | ||
|
||
## Goal | ||
|
||
Enable Kubernetes admins to specify mount options with mountable volumes | ||
such as - `nfs`, `glusterfs` or `aws-ebs` etc. | ||
|
||
## Motivation | ||
|
||
We currently support network filesystems: NFS, Glusterfs, Ceph FS, SMB (Azure file), Quobytes, and local filesystems such as ext[3|4] and XFS. | ||
|
||
Mount time options that are operationally important and have no security implications should be suppported. Examples are NFS's TCP mode, versions, lock mode, caching mode; Glusterfs's caching mode; SMB's version, locking, id mapping; and more. | ||
|
||
## Design | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. cc @kubernetes/api-reviewers @kubernetes/sig-storage-api-reviews @kubernetes/sig-auth-api-reviews |
||
We are going to add support for mount options in PVs as a beta feature to begin with. | ||
|
||
Mount options can be specified as `mountOptions` annotations in PV. For example: | ||
|
||
``` yaml | ||
apiVersion: v1 | ||
kind: PersistentVolume | ||
metadata: | ||
name: pv0003 | ||
annotations: | ||
volume.beta.kubernetes.io/mountOptions: "hard,nolock,nfsvers=3" | ||
spec: | ||
capacity: | ||
storage: 5Gi | ||
accessModes: | ||
- ReadWriteOnce | ||
persistentVolumeReclaimPolicy: Recycle | ||
nfs: | ||
path: /tmp | ||
server: 172.17.0.2 | ||
``` | ||
|
||
|
||
## Preventing users from specifying mount options in inline volume specs of Pod | ||
|
||
While mount options enable more flexibility in how volumes are mounted, it can result | ||
in user specifying options that are not supported or are known to be problematic when | ||
using inline volume specs. | ||
|
||
After much deliberation it was decided that - `mountOptions` as an API parameter will not be supported | ||
for inline volume specs. | ||
|
||
### Error handling and plugins that don't support mount option | ||
|
||
Kubernetes ships with volume plugins that don't support any kind of mount options. Such as `configmaps` or `secrets`, | ||
in those cases to prevent user from submitting volume definitions with bogus mount options - plugins can define a interface function | ||
such as: | ||
|
||
```go | ||
func SupportsMountOption() { | ||
return false | ||
} | ||
``` | ||
|
||
which will be used to validate the PV definition and API object will be *only* created if it passes the validation. Additionally | ||
support for user specified mount options will be also checked when volumes are being mounted. | ||
|
||
In other cases where plugin supports mount options (such as - `NFS` or `GlusterFS`) but mounting fails because of invalid mount | ||
option or otherwise - an Event API object will be created and attached to the appropriate object. |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
What is the security model we are working with when determining if something has
security implications
? Who are we trying to protect from what?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.
I think the definition of 'security implications' is going to be context/site dependant. This makes implementing this in a way that is safe for everybody difficult. Certainly I'd like to see the threat models being considered.