{"action":"opened","issue":{"url":"https://api.github.com/repos/quintilesims/orca/issues/24","repository_url":"https://api.github.com/repos/quintilesims/orca","labels_url":"https://api.github.com/repos/quintilesims/orca/issues/24/labels{/name}","comments_url":"https://api.github.com/repos/quintilesims/orca/issues/24/comments","events_url":"https://api.github.com/repos/quintilesims/orca/issues/24/events","html_url":"https://github.com/quintilesims/orca/issues/24","id":369332729,"node_id":"MDU6SXNzdWUzNjkzMzI3Mjk=","number":24,"title":"Implement Groups","user":{"login":"zpatrick","id":2894436,"node_id":"MDQ6VXNlcjI4OTQ0MzY=","avatar_url":"https://avatars2.githubusercontent.com/u/2894436?v=4","gravatar_id":"","url":"https://api.github.com/users/zpatrick","html_url":"https://github.com/zpatrick","followers_url":"https://api.github.com/users/zpatrick/followers","following_url":"https://api.github.com/users/zpatrick/following{/other_user}","gists_url":"https://api.github.com/users/zpatrick/gists{/gist_id}","starred_url":"https://api.github.com/users/zpatrick/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/zpatrick/subscriptions","organizations_url":"https://api.github.com/users/zpatrick/orgs","repos_url":"https://api.github.com/users/zpatrick/repos","events_url":"https://api.github.com/users/zpatrick/events{/privacy}","received_events_url":"https://api.github.com/users/zpatrick/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2018-10-11T22:39:03Z","updated_at":"2018-10-11T22:39:03Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"This ticket is intended to be a high-level discussion of possible implementations for groups, with the hope we can layout the objective pros and cons to each approach. \r\n\r\n## Actions\r\nEach implementation will need to be evaluated on how it will perform the following actions: \r\n* Create/Delete/List Groups\r\n* Update Groups' Role Bindings\r\n* Update Groups' Users\r\n* Group Management Permissions\r\n\r\n## Implementations\r\n### Auth0 Read-Only\r\nThis approach uses Auth0 as the source of truth for group membership and management. \r\nThe Orca application only performs \"read\" actions when communicating with Auth0 API, leaving most of the group management done via the Auth0 dashboard.  \r\n\r\n* Create/Delete/List Groups: Done via the Auth0 dashboard. When listing groups, Orca will need to either gather that information via Auth0, the K8s API, or a combination of both. \r\n* Update Groups' Role Bindings: Done via Orca by wrapping K8s API calls w/ role bindings. \r\n* Update Groups' Users: Done via the Auth0 dashboard. \r\n* Group Management Permissions: Handled by Auth0. \r\n\r\n#### Pros\r\n* Of all the options, would be the least amount of work to implement.\r\n* Of all the options, is the only one that doesn't need to create a custom permissions models for Group Management Permissions. \r\n* Seems to be in-line with how K8s expects user identity and group membership to be coupled. \r\n\r\n#### Cons\r\n* UX for managing group membership isn't great given one would need to switch between Orca and Auth0. \r\n* Listing groups would be somewhat difficult if that information is gathered via Auth0, since it would require looking up metadata for each user. \r\n\r\n### Auth0 Read/Write\r\nThis approach is similar to **Auth0 Read-Only**, except that we allow users to do CRUD operations for groups via Orca. \r\n\r\n* Create/Delete/List Groups: Done via the Auth0 dashboard or the Orca application. Will require the Orca application has permissions for the Auth0 Management API. When listing groups, Orca will need to either gather that information via Auth0, the K8s API, or a combination of both. \r\n* Update Groups' Role Bindings: Done via Orca by wrapping K8s API calls w/ role bindings. \r\n* Update Groups' Users: Done via the Auth0 dashboard or the Orca application. \r\n* Group Management Permissions: Would need to implement a separate permissions model to determine which users can update which groups. \r\n\r\n#### Pros\r\n* Would provide much better UX for users when managing group membership. \r\n\r\n#### Cons\r\n* Requires a custom permissions model for Group Management Permissions outside of K8s; which means users would have to understand/manage another layer security/permissions when using Orca. \r\n\r\n\r\n### K8s Custom Resources\r\nThis approach here is to use [custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) in the K8s API to help manage groups and group permissions. Auth0 would only be used as a source of authentication and identity. \r\n\r\n* Create/Delete/List Groups: Done via Orca by wrapping K8s API calls w/ custom resources. \r\n* Update Groups' Role Bindings: Done via Orca by wrapping K8s API calls w/ role bindings. \r\n* Update Groups' Users: Done via Orca by wrapping K8s API calls w/ custom resources. \r\n* Group Management Permissions: Done via Orca by wrapping K8s API calls w/ custom resources. \r\n\r\n#### Pros\r\n* Takes advantage of the existing K8s API to manage state, which is much less code/infrastructure for us to write/manage. \r\n* Doesn't implement anything that can't also be done via `kubectl`. \r\nThis could be advantageous if we (or others) wanted to make other tooling that leveraged the patterns we used with custom resources and groups. \r\n** It **might** not require a custom permissions model outside of K8s:\r\nIf there is a way to leverage the K8s RBAC permission model in limiting access to  custom resources, we could use that as our permissions model for Group Management Permissions. \r\n\r\n#### Cons\r\n* Custom Resources **might** be left hanging around after the service is deleted. \r\n* Custom Resources are unfamiliar territory: we may be trying to fit a square peg into a round hole here. \r\n* If we can't use the K8s RBAC permission model for custom resources, then we would need to create a custom permissions model for Group Management Permissions outside of K8s; which means users would have to understand/manage another layer security/permissions when using Orca. \r\n\r\n### Orca Backend\r\nThis approach here is to create a custom backend for the Orca application that manages groups and group permissions. Auth0 would only be used as a source of authentication and identity. \r\n\r\n* Create/Delete/List Groups: Done via Orca by wrapping calls to a custom backend. \r\n* Update Groups' Role Bindings: Done via Orca by wrapping K8s API calls w/ role bindings. \r\n* Update Groups' Users:  Done via Orca by wrapping calls to a custom backend. \r\n* Group Management Permissions:  Done via Orca by wrapping calls to a custom backend. \r\n\r\n#### Pros\r\n* We have full control over the backend, and can implement this in any way we see fit. \r\n\r\n#### Cons\r\n* Of all the options, requires the largest amount of work to implement. \r\n* Makes Orca the source-of-truth for group membership as it relates to Auth0 identity.\r\nWhich, at the very least, means that portion of the service should have a public-facing and well-documented API so other tools can have access to that data as well. \r\n* Requires a custom permissions model for Group Management Permissions outside of K8s; which means users would have to understand/manage another layer security/permissions when using Orca. \r\n"}}
{"actor":{"display_login":"zpatrick"}}