Closed abhinavgargin closed 3 years ago
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.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten
.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close
.
Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
Send feedback to sig-contributor-experience at kubernetes/community. /close
@fejta-bot: Closing this issue.
Bug Report
What happened: Originating identity is not propagating in case of service instance creation. My team is using a service account to operate as a platform component. When a user(application developer) sends a request to create an instance, the created instance has our service-account as the username/userid. The originating identity flag has been set to true and I can see the user details in case of binding. But in case of instance creation behavior is unexpected.
What you expected to happen: The user, who initiated the service instance creation request, should get his/her username in the object details.
How to reproduce it (as minimally and precisely as possible): Use a service account which has elevated privileges to perform operations on Kubernetes platform. Apply a service instance creation yaml and you would see service account in created object's details.
Anything else we need to know?:
Environment:
kubectl version
): 1.17