Track which user created resources #13925

smarterclayton · 2015-09-14T16:37:37Z

Adds creationUserName which records the creating user in the resource
for use in audit scenarios. Set by the system automatically to the user
name returned by the authentication plugin. Clients must assume that the
name value may be machine-readable and therefore is not guaranteed to be
a pretty name.

Fixes #13306

This change is

smarterclayton · 2015-09-14T16:38:41Z

@kubernetes/kube-api - the proposal didn't get many comments but this adds a new metadata field to track created users.

derekwaynecarr · 2015-09-14T17:39:25Z

I assume CreationUserName is preferred over Creator because it aligns with CreationTimestamp?

derekwaynecarr · 2015-09-14T17:40:48Z

pkg/api/meta.go

@@ -25,6 +25,9 @@ import (
 // FillObjectMetaSystemFields populates fields that are managed by the system on ObjectMeta.
 func FillObjectMetaSystemFields(ctx Context, meta *ObjectMeta) {
 	meta.CreationTimestamp = util.Now()
+	if user, ok := UserFrom(ctx); ok {


When would there never be a user?

Yes, I don't want to create new names even if the english is slightly
weird. We're fairly good at "" in our API - "creation" is
the concept, "type" is "UserName", "Timestamp", "PeriodInSeconds", "Name",
"Ref"

On Mon, Sep 14, 2015 at 1:41 PM, Derek Carr [email protected]
wrote:

In pkg/api/meta.go
#13925 (comment)
:

@@ -25,6 +25,9 @@ import (
// FillObjectMetaSystemFields populates fields that are managed by the system on ObjectMeta.
func FillObjectMetaSystemFields(ctx Context, meta *ObjectMeta) {
meta.CreationTimestamp = util.Now()

if user, ok := UserFrom(ctx); ok {

When would there never be a user?

—
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/kubernetes/pull/13925/files#r39422744.

Clayton Coleman | Lead Engineer, OpenShift

There could not be a user if it's an object created before this change went
in, created by a core system process (like endpoints and namespaces created
by the master on startup), or created by direct edit in etcd that does not
require authentication. Or a cluster that doesn't require authentication
or doesn't pass that info to Kube.

On Mon, Sep 14, 2015 at 2:08 PM, Clayton Coleman [email protected]
wrote:

Yes, I don't want to create new names even if the english is slightly
weird. We're fairly good at "" in our API - "creation" is
the concept, "type" is "UserName", "Timestamp", "PeriodInSeconds", "Name",
"Ref"

On Mon, Sep 14, 2015 at 1:41 PM, Derek Carr [email protected]
wrote:

In pkg/api/meta.go
#13925 (comment)
:

@@ -25,6 +25,9 @@ import (
// FillObjectMetaSystemFields populates fields that are managed by the system on ObjectMeta.
func FillObjectMetaSystemFields(ctx Context, meta *ObjectMeta) {
meta.CreationTimestamp = util.Now()

if user, ok := UserFrom(ctx); ok {

When would there never be a user?

—
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/kubernetes/pull/13925/files#r39422744.

Clayton Coleman | Lead Engineer, OpenShift

Clayton Coleman | Lead Engineer, OpenShift

smarterclayton · 2015-09-14T21:16:23Z

ok to test

smarterclayton · 2015-09-16T02:56:02Z

@bgrant0607 let me know if the naming makes sense here

bgrant0607 · 2015-09-16T05:23:48Z

I understand that you want a field that can't be set/modified by the client, as opposed to an annotation. I'm fine with that.

CreationUserName seems fine with respect to the field naming conventions.

I also like that CreationUserName makes it clear that it's a user name and not, for instance, a controller name.

What I don't know is what our plans for User concepts/APIs are. Is "UserName" consistent with our current thinking in that direction? @erictune? @liggitt? @derekwaynecarr?

deads2k · 2015-09-16T13:47:16Z

pkg/api/validation/validation.go

@@ -273,6 +273,12 @@ func ValidateObjectMetaUpdate(new, old *api.ObjectMeta) errs.ValidationErrorList
 	} else {
 		new.CreationTimestamp = old.CreationTimestamp
 	}
+	// ignore changes to user name
+	if len(old.CreationUserName) == 0 {
+		old.CreationUserName = new.CreationUserName


If it was empty before, it seems weird to allow it to be updated later.

It was to allow an automated process to update it for legacy data. So
someone upgrading from Kube 1.0 would be able to be assigned the value. I
can disable the ability to set it post creation, which means we have no API
path to ever set that value and would have to write directly to etcd.
Allowing it to be set from empty to something post create has potential for
abuse.

On Sep 16, 2015, at 9:47 AM, David Eads [email protected] wrote:

In pkg/api/validation/validation.go
#13925 (comment):

@@ -273,6 +273,12 @@ func ValidateObjectMetaUpdate(new, old *api.ObjectMeta) errs.ValidationErrorList
} else {
new.CreationTimestamp = old.CreationTimestamp
}

// ignore changes to user name

if len(old.CreationUserName) == 0 {

old.CreationUserName = new.CreationUserName

If it was empty before, it seems weird to allow it to be updated later.

—
Reply to this email directly or view it on GitHub
https://github.com/kubernetes/kubernetes/pull/13925/files#r39630766.

+1 for making it immutable by default

smarterclayton · 2015-09-16T16:44:21Z

On Sep 16, 2015, at 1:24 AM, Brian Grant [email protected] wrote:

I understand that you want a field that can't be set/modified by the
client, as opposed to an annotation. I'm fine with that.

CreationUserName seems fine with respect to the field naming conventions.

I also like that CreationUserName makes it clear that it's a user name and
not, for instance, a controller name.

What I don't know is what our plans for User concepts/APIs are. Is
"UserName" consistent with our current thinking in that direction? @erictune
https://github.com/erictune? @liggitt https://github.com/liggitt?
@derekwaynecarr https://github.com/derekwaynecarr?

As defined in our authentication patterns we settled on UserName as the
unique in space name for a user. We don't have a way to enforce uniqueness
for time and space today within Kube (in Openshift we do) because
underlying auth providers are responsible for that (as defined by their
system). An admin is free to let their username not be stable if they
like. I would maybe argue in the future to expand this to include userUID,
but not required for step one.

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

liggitt · 2015-09-16T16:57:39Z

CreationUserName seems ok. The user.Info interface has both Name() and UID(). Do we want to preserve both (that gets us point in time uniqueness as well).

smarterclayton · 2015-09-16T17:06:35Z

I wanted to make the minimal change here to start down the path. If
everyone is ok with UID(), we can add it. On the other hand, we can easily
add it later.

On Wed, Sep 16, 2015 at 12:57 PM, Jordan Liggitt [email protected]
wrote:

CreationUserName seems ok. The user.Info interface has both Name() and
UID(). Do we want to preserve both (that gets us point in time uniqueness
as well).

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

Clayton Coleman | Lead Engineer, OpenShift

Adds `creationUserName` which records the creating user in the resource for use in audit scenarios. Set by the system automatically to the user name returned by the authentication plugin. Clients must assume that the name value may be machine-readable and therefore is not guaranteed to be a pretty name.

smarterclayton · 2015-09-18T14:29:33Z

Rebased. This is as minimal a change as I can make that provides real value. Do we have consensus on creationUserName as the name? I think we can add creationUserUID in the future. Other thoughts?

deads2k · 2015-09-18T14:43:33Z

code lgtm.

I like username as a starting point.

erictune · 2015-10-29T17:51:51Z

@saad-ali because he ❤️ events.

smarterclayton · 2015-12-25T04:34:16Z

Downside is that is a lot more events. Also, today at least events are owned by a namespace so they can be deleted when the namespace is deleted.

erictune · 2015-12-26T17:45:14Z

It may be worth comparing with other IaaS/PaaS APIs which are mature enough
to have well-developed audit capabilities. I picked cloud foundry and
openstack for comparison.

cloud foundry apps have the following metadata: uid, object name,
"created_at", "updated_at" (source:
https://apidocs.cloudfoundry.org/226/apps_(experimental)/starting_an_app.html
)
cloud foundry API audit trail is accessed with cf events command.
(source: https://docs.cloudfoundry.org/concepts/security.html#logging)
openstack metadata includes a request ID, creation time, object uid,
object name (source:
http://developer.openstack.org/api-ref-compute-v2.1.html)
openstack auditing is an optional feature (source:
http://docs.openstack.org/developer/keystonemiddleware/audit.html). It uses
a log format which records events (source:
https://www.dmtf.org/sites/default/files/standards/documents/DSP2038_1.1.0.pdf
)

On Thu, Dec 24, 2015 at 8:35 PM, Clayton Coleman [email protected]
wrote:

Downside is that is a lot more events. Also, today at least events are
owned by a namespace so they can be deleted when the namespace is deleted.

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

smarterclayton · 2015-12-26T19:00:10Z

The salesforce metadata is another good metric of what and end state metadata audit looks like: https://help.salesforce.com/apex/HTViewHelpDoc?id=field_audit_trail.htm&language=en_US Tracks creator and updater. I think event tracking makes a lot of sense for approaching audit, but does require more thought in how events are implemented and handled. For instance, having events warehoused, survive namespace deletion, and protected/exposed safely to end users.

cameronbrunner · 2016-01-26T17:39:33Z

Just curious how this request is progressing. Specifically the created-by-user is of great interest but not for an audit perspective but more as a pod attribute. As discussed in #19079 (and sorry for those who have read both of these comments!) I am interested in this as we are working on integrating our scheduler (Grid Engine) with kubernetes and from our past experience user ownership of compute tasks is important when organizations implement resource allocation policies. It would be useful for us to be able to quota against users, favor pods created by one user over another, and group pods of certain users under hierarchical organizational groups. With our scheduler we could do just about all of this now in kubernetes if there was a user tag on resources.

erictune · 2016-01-31T19:13:05Z

@cameronbrunner Resources are often created by controllers in kubernetes, not end-users. Before we can have this feature in a useful way, we would need to implement acting-as #16933.

cameronbrunner · 2016-02-01T22:09:34Z

@erictune Thanks for the reference to #16933 thats definitely covering the ownership issue with resource creation inside of controllers in general. I was thinking I was going to have to have to do something on my own here so its good to see that people have already been thinking about this:)

fejta · 2016-04-26T07:21:55Z

This PR has had no meaningful activity for multiple months. If it is still valid please rebase, push a new commit and reopen the PR. Thanks!

davidopp · 2016-04-26T08:59:50Z

Why did we drop this? It seems useful.

k8s-bot · 2016-04-26T09:09:28Z

GCE e2e build/test failed for commit a3d32f9.

Please reference the list of currently known flakes when examining this failure. If you request a re-test, you must reference the issue describing the flake.

aanm · 2016-05-13T20:35:30Z

@erictune @smarterclayton Since #23549 was merged, what is the current progress with this PR? Let me know if I can help with anything.

bgrant0607 · 2016-05-20T17:18:22Z

cc @mikedanese

erictune · 2016-06-30T17:50:10Z

#27087 will add a detailed audit log.

We should see how many use cases that satisfies (I know it does not satisfy @cameronbrunner use case, but want to see how many other need this after we have an audit log).

Also, submitting this before we have implemented controllers that use "acting-as" will mean that we have to do a breaking change once we add "acting-as" support. So, we should do that first, and then reevaluate this.

erictune · 2016-06-30T17:51:01Z

@aanm It would be helpful if you could describe in detail how you would use this field.

aanm · 2016-07-04T13:37:24Z

@erictune It would help to allow or deny network traffic from/to a particular user.

tgraf · 2016-07-04T15:06:57Z

@erictune The use case is derived from the Net-SIG NetworkPolicy decision which now allows ingress rules based on PodSelector. We would like to allow for the creation of rules based on who has created/is running a particular pod.

erictune · 2016-07-06T18:09:20Z

Why not do this based on the service account of the pod? This allows two good things:

a single human can create different pods with different network policies
multiple humans can collaborate in the management of pods for an important service.

soltysh · 2016-07-07T07:41:57Z

@sttts fyi

k8s-bot · 2016-08-30T00:38:20Z

Can one of the admins verify that this patch is reasonable to test? If so, please reply "ok to test".
(Note: "add to whitelist" is no longer supported. Please update configurations in kubernetes/test-infra/jenkins/job-configs/kubernetes-jenkins-pull instead.)

This message will repeat several times in short succession due to jenkinsci/ghprb-plugin#292. Sorry.

k8s-github-robot · 2016-10-05T07:52:55Z

This PR hasn't been active in 90 days. Closing this PR. Please reopen if you would like to work towards merging this change, if/when the PR is ready for the next round of review.

cc @erictune @smarterclayton

You can add 'keep-open' label to prevent this from happening again, or add a comment to keep it open another 90 days

googlebot added the cla: yes label Sep 14, 2015

smarterclayton mentioned this pull request Sep 14, 2015

Proposal: Record which user created an object #13306

Closed

smarterclayton added area/security area/api Indicates an issue on api area. area/apiserver labels Sep 14, 2015

derekwaynecarr reviewed Sep 14, 2015
View reviewed changes

j3ffml assigned bgrant0607 Sep 14, 2015

k8s-github-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Sep 14, 2015

bgrant0607 assigned erictune and unassigned bgrant0607 Sep 16, 2015

deads2k reviewed Sep 16, 2015
View reviewed changes

smarterclayton force-pushed the add_creation_username branch from 2fc55dc to 4023b9c Compare September 16, 2015 17:11

smarterclayton closed this Sep 17, 2015

smarterclayton reopened this Sep 17, 2015

k8s-github-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 17, 2015

smarterclayton force-pushed the add_creation_username branch from 4023b9c to c163105 Compare September 18, 2015 03:52

k8s-github-robot added needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. and removed needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. labels Sep 18, 2015

smarterclayton force-pushed the add_creation_username branch from c163105 to a3d32f9 Compare September 18, 2015 14:24

smarterclayton mentioned this pull request Nov 1, 2015

[WIP] Add wmftoolsenforcer admission controller #16250

Closed

deads2k mentioned this pull request Jan 6, 2016

Representation of Organizational Entites #19079

Closed

cameronbrunner mentioned this pull request Feb 1, 2016

Added proposal for "acting-as". #16933

Closed

k8s-github-robot added the release-note-label-needed label Mar 31, 2016

fejta closed this Apr 26, 2016

davidopp reopened this Apr 26, 2016

erictune added the sig/auth Categorizes an issue or PR as relevant to SIG Auth. label Jun 30, 2016

k8s-github-robot closed this Oct 5, 2016

liggitt mentioned this pull request Oct 24, 2016

WIP Quobyte - Use Service Account as default #35412

Closed

bgrant0607 mentioned this pull request Jan 24, 2017

Proposal: Extensible Admission Control kubernetes/community#132

Merged

Track which user created resources #13925

Track which user created resources #13925

Uh oh!

Conversation

smarterclayton commented Sep 14, 2015 • edited by k8s-github-robot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

smarterclayton commented Sep 14, 2015

Uh oh!

derekwaynecarr commented Sep 14, 2015

Uh oh!

derekwaynecarr Sep 14, 2015

Choose a reason for hiding this comment

Uh oh!

smarterclayton Sep 14, 2015

Choose a reason for hiding this comment

Uh oh!

smarterclayton Sep 14, 2015

Choose a reason for hiding this comment

Uh oh!

smarterclayton commented Sep 14, 2015

Uh oh!

smarterclayton commented Sep 16, 2015

Uh oh!

bgrant0607 commented Sep 16, 2015

Uh oh!

deads2k Sep 16, 2015

Choose a reason for hiding this comment

Uh oh!

smarterclayton Sep 16, 2015

Choose a reason for hiding this comment

Uh oh!

liggitt Sep 16, 2015

Choose a reason for hiding this comment

Uh oh!

smarterclayton commented Sep 16, 2015

Uh oh!

liggitt commented Sep 16, 2015

Uh oh!

smarterclayton commented Sep 16, 2015

Uh oh!

smarterclayton commented Sep 18, 2015

Uh oh!

deads2k commented Sep 18, 2015

Uh oh!

erictune commented Oct 29, 2015

Uh oh!

smarterclayton commented Dec 25, 2015

Uh oh!

erictune commented Dec 26, 2015

Uh oh!

smarterclayton commented Dec 26, 2015 via email

Uh oh!

cameronbrunner commented Jan 26, 2016

Uh oh!

erictune commented Jan 31, 2016

Uh oh!

cameronbrunner commented Feb 1, 2016

Uh oh!

fejta commented Apr 26, 2016

Uh oh!

davidopp commented Apr 26, 2016

Uh oh!

k8s-bot commented Apr 26, 2016

Uh oh!

aanm commented May 13, 2016

Uh oh!

bgrant0607 commented May 20, 2016

Uh oh!

erictune commented Jun 30, 2016

Uh oh!

erictune commented Jun 30, 2016

Uh oh!

aanm commented Jul 4, 2016

Uh oh!

tgraf commented Jul 4, 2016

Uh oh!

erictune commented Jul 6, 2016

Uh oh!

soltysh commented Jul 7, 2016

smarterclayton commented Sep 14, 2015 •

edited by k8s-github-robot

Loading