You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@yunikorn.apache.org by "Amit Sharma (Jira)" <ji...@apache.org> on 2021/04/21 17:53:00 UTC
[jira] [Updated] (YUNIKORN-649) Require improved methodology for
determining k8s user
[ https://issues.apache.org/jira/browse/YUNIKORN-649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amit Sharma updated YUNIKORN-649:
---------------------------------
Description:
The Kubernetes metadata does not carry user information by design. This can be referred here.
[https://kubernetes.io/docs/reference/access-authn-authz/authentication/]
Here is how Yunikorn determines the user from k8s metadata (Service Account)
[https://github.com/apache/incubator-yunikorn-k8shim/blob/7648f29e50692fbb760480c586f8e3a1110eb15b/pkg/appmgmt/general/general.go#L126]
The only thing close to any identity is a ServiceAccount. However, this is not the ideal way of looking at identities as there is no authentication mechanism for the service account directly. It relies on the authentication mechanism deployed on the cluster. The cluster authentication mechanism varies from deployment to deployment.
There are 2 possible ways of doing this.
1) One generic solution can be to modify the source of the user from ServiceAccount to a Label/Annotation.
2) Extending point 1, instead of changing from service account to label/annotation, it can be a configurable field which defaults to Label/Annotation.
While point 2 provides more user flexibility, it also reduces the structure or clear path that Yunikorn can follow in determining a user.
Since Yunikorn is expected to be primarily deployed by owners of a Kubernetes platform rather than individual applications, we can share a structure using point 1 as a solution.
Please share your thoughts.
was:
The Kubernetes metadata does not carry user information by design. This can be referred here.
[https://kubernetes.io/docs/reference/access-authn-authz/authentication/]
The only thing close to any identity is a ServiceAccount. However, this is not the ideal way of looking at identities as there is no authentication mechanism for the service account directly. It relies on the authentication mechanism deployed on the cluster. The cluster authentication mechanism varies from deployment to deployment.
There are 2 possible ways of doing this.
1) One generic solution can be to modify the source of the user from ServiceAccount to a Label/Annotation.
2) Extending point 1, instead of changing from service account to label/annotation, it can be a configurable field which defaults to Label/Annotation.
While point 2 provides more user flexibility, it also reduces the structure or clear path that Yunikorn can follow in determining a user.
Since Yunikorn is expected to be primarily deployed by owners of a Kubernetes platform rather than individual applications, we can share a structure using point 1 as a solution.
Please share your thoughts.
> Require improved methodology for determining k8s user
> -----------------------------------------------------
>
> Key: YUNIKORN-649
> URL: https://issues.apache.org/jira/browse/YUNIKORN-649
> Project: Apache YuniKorn
> Issue Type: Improvement
> Components: shim - kubernetes
> Reporter: Amit Sharma
> Priority: Major
>
> The Kubernetes metadata does not carry user information by design. This can be referred here.
> [https://kubernetes.io/docs/reference/access-authn-authz/authentication/]
> Here is how Yunikorn determines the user from k8s metadata (Service Account)
> [https://github.com/apache/incubator-yunikorn-k8shim/blob/7648f29e50692fbb760480c586f8e3a1110eb15b/pkg/appmgmt/general/general.go#L126]
>
> The only thing close to any identity is a ServiceAccount. However, this is not the ideal way of looking at identities as there is no authentication mechanism for the service account directly. It relies on the authentication mechanism deployed on the cluster. The cluster authentication mechanism varies from deployment to deployment.
> There are 2 possible ways of doing this.
> 1) One generic solution can be to modify the source of the user from ServiceAccount to a Label/Annotation.
> 2) Extending point 1, instead of changing from service account to label/annotation, it can be a configurable field which defaults to Label/Annotation.
> While point 2 provides more user flexibility, it also reduces the structure or clear path that Yunikorn can follow in determining a user.
> Since Yunikorn is expected to be primarily deployed by owners of a Kubernetes platform rather than individual applications, we can share a structure using point 1 as a solution.
> Please share your thoughts.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@yunikorn.apache.org
For additional commands, e-mail: issues-help@yunikorn.apache.org