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
Pod level SELinux context and volumes #14192
Conversation
GCE e2e build/test passed for commit 73cb59af1d516e0111e1036906ed88e38c06d35f. |
Labelling this PR as size/L |
I think |
@rootfs Is what you're proposing only for shared storage? Remote block devices should support writing SELinux xattrs just fine. |
Needs backcompat statement filled out. |
@smarterclayton Oh yes, I'm aware :) That's next. On Mon, Sep 21, 2015 at 12:14 PM, Clayton Coleman notifications@github.com
|
switching review to @smarterclayton since he has SELinux context that I lack. |
I agree with all of this, but I would like @thockin to once over because of general volume design and @bgrant0607 to ack the API change that I believe he was ok with in the parent issue. |
|
||
#### API backward compatibility | ||
|
||
TODO |
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.
???
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.
@bgrant0607 Also on my list for today, this depended on getting the story right with #12823 before it could be done without wasting time. The story I'm going to write today is much simpler than the one I would have written when the TODO went in.
73cb59a
to
9246618
Compare
GCE e2e build/test passed for commit 92466181f93adc582df2ed77848eb091cd93aae7. |
9246618
to
b2e967e
Compare
@thockin Most of your feedback should be addressed mod block devices in read-only mode. |
@swagiaal @pweil- @rootfs @childsb @wattsteve |
Unit, integration and GCE e2e test build/test passed for commit b2e967e. |
Travis says: run hack/update-generated-docs.sh |
|
||
Kubernetes volumes can be divided into two broad categories: | ||
|
||
1. Unshared storage: |
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.
This taxonomy is really the same as the PV taxonomy: RWO, ROX, RWX
Specifically your 1.2 is a lie. Most block devices support single-writer or multi-reader modes
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.
ack; I'll rewrite.
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.
@thockin So, is it really that 1.2 needs to be split into:
- Use of network block devices without using PVs
- Use of network block devices with PVs in
ReadWriteOnce
mode - Use of network block devices with PVs in
*Many
modes
I think (1) and (2) go where 1.2 is now, and (3) should be another bullet in 'shared storage'
@markturansky @wattsteve @childsb @swagiaal
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 use of "Unshared" vs "Shared" is confusing here. The real dividing line is "Volumes which support client side chcon" and "volumes which do not"
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 don't agree, @swagiaal. For example, in the use-case where you have a network block device being used via a PV in ReadOnlyMany
mode, I don't think you want to do the chcon, even though the block device supports it. I think that falls into the same category as NFS, where you can't really do the chcon from the client side (due to the security risk you take on) even if you're in ReadWriteOnce
PV mode.
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.
To expand a little bit more, if you're using a block device-based volume that supports chcon
in one of the Many
PV modes, I think you have problems similar to 'shared' FSs like NFS, etc:
- Which context is the right one to use?
- How should manage the context?
I'm inclined to say the right point at which to solve the above questions is when such a volume is provisioned rather than when it is mounted into a pod.
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'm leaning towards rewriting this section when I make a pass back through this doc.
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.
@wattsteve @childsb Opinions welcome, since this recasts the framework we've been talking about volumes in terms of slightly. PTAL
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.
@swagiaal For the record, I didn't disagree about being confusing, only on how you were partitioning the space of volumes/FSs.
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 we should lump the 1 write multiple read use case into the shared storage category and fully address it in the next iteration.
b2e967e
to
dd2a3bf
Compare
Unit, integration and GCE e2e build/test failed for commit dd2a3bfcd35f3bf060cafad6d651c2b31a4ad0f5. |
dd2a3bf
to
f37423e
Compare
f37423e
to
7f049b7
Compare
@thockin I think this should be ready for review now. How about I owe you one beer per PR?* *terms and conditions apply |
Unit, integration and GCE e2e build/test failed for commit f37423e4690e4c46e6addf77c64ffef53e4960ca. |
Unit, integration and GCE e2e test build/test passed for commit 7f049b7. |
### Kubernetes | ||
|
||
|
||
There is a [proposed change](https://github.com/GoogleCloudPlatform/kubernetes/pull/9844) to the |
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.
does this mean we close #9844?
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.
Already closed!
L |
Thanks a lot @thockin |
+1 for that On Oct 2, 2015, at 2:36 PM, Paul Morie notifications@github.com wrote: Thanks a lot @thockin https://github.com/thockin — |
Pod level SELinux context and volumes
Pod level SELinux context and volumes
Splitting from #12944; this proposal covers just SELinux and generic label management for volumes.
Next step is discussion of API backward compatibility issues.
@pweil- @swagiaal @smarterclayton @childsb @wattsteve