[
https://issues.apache.org/jira/browse/YUNIKORN-649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17326904#comment-17326904
]
Weiwei Yang commented on YUNIKORN-649:
--------------------------------------
hi [~avsamit6600]
You are right, with labels, it is easier to filter with selectors. We can go
with labels.
Just one suggestion is to add the domain name: yunikorn.apache.org/ as the
prefix of the field, to indicate this is a reserved label name by YK.
The ACL feature will depend on this:
http://yunikorn.apache.org/docs/next/user_guide/acls. Once this is done, we
need to update the doc accordingly, let users know how to define users, and how
to apply the ACLs.
For implementation, I think we can safely remove the old impl that uses
serviceAccount, it is not used by anyone anyway. Let's use this generic
solution, the label to represent the user identity in YK.
I am changing this to an umbrella and some initial sub-tasks. Thanks!
> 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
> Assignee: 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: [email protected]
For additional commands, e-mail: [email protected]
