Apiserver Proxy should pass impersonated user information to kube-apiserver

[pbochynski]

Description

Authorization Proxy calls APIserver with service account kyma-system:kube-rbac-proxy. The information about the end user is only passed to kubernetes authorizer but it is not passed to apiserver when request is executed. As a result in the apiserver audit log all the entries made through authorization proxy are assigned to service account only (user information is missing).
Authorization proxy should add Impersonate-User header to requests with value extracted from ID Token.

Expected result
APIserver audit log contains information about the user who made the request to authorization proxy.
Example:

{
 insertId:  "c5b90d47-0112-4c79-bc6d-e55b565d681f"  
 labels: {
  authorization.k8s.io/decision:  "allow"   
  authorization.k8s.io/reason:  "RBAC: allowed by ClusterRoleBinding "kyma-admin-binding" of ClusterRole "kyma-admin" to User "admin@kyma.cx""   
 }
 logName:  ".../logs/cloudaudit.googleapis.com%2Fdata_access"  
 operation: {…}  
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"   
  authenticationInfo: {
   authoritySelector:  "admin@kyma.cx"    
   principalEmail:  "system:serviceaccount:kyma-system:kube-rbac-proxy"    
  }
  authorizationInfo: [1]   
  methodName:  "io.k8s.core.v1.pods\.list"   
  requestMetadata: {…}   
  resourceName:  "core/v1/namespaces/default/pods\"   
  serviceName:  "k8s.io"   
  status: {…}   
 }
 receiveTimestamp:  "2019-02-20T12:55:00.288337416Z"  
 resource: {…}  
 timestamp:  "2019-02-20T12:54:50.424015Z"  
}

Actual result
Only service account is visible in audit log:

{
 insertId:  "40e2f0bb-5678-486a-9ac7-92ba73b06354"  
 labels: {
  authorization.k8s.io/decision:  "allow"   
  authorization.k8s.io/reason:  "RBAC: allowed by ClusterRoleBinding "kyma-admin-binding" of ClusterRole "kyma-admin" to ServiceAccount "kube-rbac-proxy/kyma-system""   
 }
 logName:  ".../logs/cloudaudit.googleapis.com%2Fdata_access"  
 operation: {…}  
 protoPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.AuditLog"   
  authenticationInfo: {
   principalEmail:  "system:serviceaccount:kyma-system:kube-rbac-proxy"    
  }
  authorizationInfo: [1]   
  methodName:  "io.k8s.core.v1.pods.list"   
  requestMetadata: {…}   
  resourceName:  "core/v1/namespaces/default/pods"   
  serviceName:  "k8s.io"   
  status: {…}   
 }
 receiveTimestamp:  "2019-02-20T12:50:58.443677458Z"  
 resource: {…}  
 timestamp:  "2019-02-20T12:50:26.221004Z"  
}

Steps to reproduce
Get pods with user id token through apiserver proxy:

curl -H "Authorization: Bearer $token" "https://apiserver.{yourcluster}/api/v1/namespaces/default/pods"

and check audit log.

If you add header Impersonate-User: admin@kyma.cx the audit log contains user information.

curl -H "Authorization: Bearer $token" -H "Impersonate-User: admin@kyma.cx" "https://apiserver.{yourcluster}/api/v1/namespaces/default/pods"

[pbochynski]

Please verify if it is still required to call authorizer before you forward call to apiserver. I think apiserver will verify impersonated user anyway and you can skip one step.

And the same solution should be applied in UI API Layer component.

[piotrmsc]

We have to address also impersonate-group which is available as well. If the impersonate-user header is added in the request to the proxy, we have to validate it against user in the token.

[stale]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[piotrmsc]

Impersonation is already done in the proxy with users and groups