I have no issue adding this, but I think we need to make careful usage of it.

I will refer to:
#3585

Your scenario is not fully captured in this PR, but it appears that at the moment, if an admission decision is tied to the user.Info, but is not able to be expressed via Policy, then the only choice right now is to use admission control.

Moving forward, I would like to know how we can log the necessary information to allow the same pattern to be supported as an initializer post Kube 1.0 that can run prior to scheduling. For example, if we had access to an audit log of who did what to what resource, could that be coupled to do the right thing in a latent initializer for the future scenario.

Yeah, or how can context be passed remotely. Can we not just add explicit user info to the admission context?

On May 13, 2015, at 5:23 PM, Derek Carr notifications@github.com wrote:

I have no issue adding this, but I think we need to make careful usage of it.

I will refer to:
#3585

Your scenario is not fully captured in this PR, but it appears that at the moment, if an admission decision is tied to the user.Info, but is not able to be expressed via Policy, then the only choice right now is to use admission control.

Moving forward, I would like to know how we can log the necessary information to allow the same pattern to be supported as an initializer post Kube 1.0 that can run prior to scheduling. For example, if we had access to an audit log of who did what to what resource, could that be coupled to do the right thing in a latent initializer for the future scenario.

—
Reply to this email directly or view it on GitHub.

Agree with Clayton, add what you explicitly need rather than full context so we know what on the context is actually used as we move scenario to some type of controller post 1.0

Sent from my iPhone

On May 13, 2015, at 9:06 PM, Clayton Coleman notifications@github.com wrote:

Yeah, or how can context be passed remotely. Can we not just add explicit user info to the admission context?

On May 13, 2015, at 5:23 PM, Derek Carr notifications@github.com wrote:

I have no issue adding this, but I think we need to make careful usage of it.

I will refer to:
#3585

Your scenario is not fully captured in this PR, but it appears that at the moment, if an admission decision is tied to the user.Info, but is not able to be expressed via Policy, then the only choice right now is to use admission control.

Moving forward, I would like to know how we can log the necessary information to allow the same pattern to be supported as an initializer post Kube 1.0 that can run prior to scheduling. For example, if we had access to an audit log of who did what to what resource, could that be coupled to do the right thing in a latent initializer for the future scenario.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub.

Sure, will update to only pass UserInfo rather than the whole context.

I like this change and I need it in OpenShift to support securing access to service accounts.

LGTM, will give the day before merging for any other comments.

Merging