I think I have one reservation and one question:

1. Events. Right now event validation allows an empty namespace. Truth be told, I don't know how they're actually stored if they have no namespace, but I think that it is reasonable to have the idea of a cluster level event that contains values for several of those fields including "user object names" and "user labels and annotations".
2. Audit log? I haven't seen much action on this, but it is a common request and one way of satisfying it would be to provide access via our API. I very much doubt that it would be an API object itself, but I could imagine it being shaped similarly for consistent consumption. Would this statement preclude that kind of exposure?

Maybe we need an additional qualification like "non-privileged, non-namespaced"?

Events without a namespace get stuck into "default". It is ... Sort of
ugly.
On Feb 19, 2016 9:45 AM, "David Eads" notifications@github.com wrote:

I think I have one reservation and one question:

Events. Right now event validation allows an empty namespace. Truth be
told, I don't know how they're actually stored if they have no namespace,
but I think that it is reasonable to have the idea of a cluster level event
that contains values for several of those fields including "user object
names" and "user labels and annotations".
2.

Audit log? I haven't seen much action on this, but it is a common
request and one way of satisfying it would be to provide access via our
API. I very much doubt that it would be an API object itself, but I could
imagine it being shaped similarly for consistent consumption. Would this
statement preclude that kind of exposure?

—
Reply to this email directly or view it on GitHub
#21560 (comment)
.

Maybe we need an additional qualification like "non-privileged, non-namespaced"?

I think that would do for me. I can also see trying to avoid exposure unless the reverse lookup capability is absolutely required (like the event case).

I've been lobbying for field-level ACLs for a while now (there was a relevant issue but I can't find it ATM), which I think might be another way to approach this. I had originally envisioned it as just a write ACL (for example, admin can configure cluster so that only schedulers can write nodeName, or only controllers can write controllerRef) but I guess in theory you could have a read ACL also. In this specific case, you could put image name in the NodeStatus but only make it readable by principals with the needed authorization, such as the scheduler (unauthorized principals would get some sentinel that means insufficient permission). There are definitely some details to work out, like would you have to auth to kubelet or would we just say you have to go through the API server, but I think that if the mechanism existed it might be able to address the problem discussed there.

Sorry, that comment was supposed to go in #21182, but anyway...

I have started to appreciate the idea of subresources as the gateway to
ACL'ed mutating operations. I like it less for sub-object scope
read-ACLing.

E.g. user can set Pod.spec.nodeName at creation, but thereafter it has to
go through a .../bind subresource to be mutated.

On Sat, Feb 20, 2016 at 4:33 PM, David Oppenheimer <notifications@github.com

wrote:

I've been lobbying for field-level ACLs for a while now (there was a
relevant issue but I can't find it ATM), which I think might be another way
to approach this. I had originally envisioned it as just a write ACL (for
example, admin can configure cluster so that only schedulers can write
nodeName, or only controllers can write controllerRef) but I guess in
theory you could have a read ACL also. In this specific case, you could put
image name in the NodeStatus but only make it readable by principals with
the needed authorization, such as the scheduler (unauthorized principals
would get some sentinel that means insufficient permission). There are
definitely some details to work out, like would you have to auth to kubelet
or would we just say you have to go through the API server, but I think
that if the mechanism existed it might be able to address the problem
discussed there.

—
Reply to this email directly or view it on GitHub
#21560 (comment)
.

Not to rathole on the nodeName thing, but there's really no reason a user should need to set it in normal managed clusters. They should use node affinity (like Borg hostname constraint), which expresses the same intent but gives the scheduler a say.

I don't think subresource solves the problem in general. For example, with controllerRef I think we don't want the user to be able to set it at all.

What is the downside of per-field ACLs (specified on a per API group/kind basis)? Having to put every write-ACLd field behind a subresource seems tedious, and also doesn't let you forbid writing the field at creation time.

Not being able to set it at creation time can be controlled independently
from who can update it. e.g. AdmissionControl can reject any Pod with
NodeName set, but we can still allow controlled updates via a /bind
subresource/verb.

On Sat, Feb 20, 2016 at 5:17 PM, David Oppenheimer <notifications@github.com

wrote:

Not to rathole on the nodeName thing, but there's really no reason a user
should need to set it in normal managed clusters. They should use node
affinity (like Borg hostname constraint), which expresses the same intent
but gives the scheduler a say.

I don't think subresource solves the problem in general. For example, with
controllerRef I think we don't want the user to be able to set it at all.

What is the downside of per-field ACLs (specified on a per API group/kind
basis)? Having to put every write-ACLd field behind a subresource seems
tedious, and also doesn't let you forbid writing the field at creation time.

—
Reply to this email directly or view it on GitHub
#21560 (comment)
.

IIUC admission control is also invoked on update, so shouldn't we be able to use admission controllers to enforce arbitrary ACL rules on both creation and update?

My point was to avoid any sort of per-field-per-user ACLing.

On Sat, Feb 20, 2016 at 6:08 PM, David Oppenheimer <notifications@github.com

wrote:

IIUC admission control is also invoked on update, so shouldn't we be able
to use admission controllers to enforce arbitrary ACL rules on both
creation and update?

—
Reply to this email directly or view it on GitHub
#21560 (comment)
.

This originally was about reads rather than writes.

/sig api-machinery

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

/remove-lifecycle stale
/lifecycle frozen

@bgrant0607 any chance of followup? This seems useful to have codified.