Initial draft of an "enterprise ready" enhancement. #55
Conversation
|
Perhaps having a ready reference to this security handbook added in the Datum wiki would be useful in this exercise - []https://docs.google.com/document/d/1LIFqxiHEI_bHmcEj6Gm12uPoe4ZIycp87qdwwRvnE_A/edit?usp=drive_link |
There was a problem hiding this comment.
This is great - thanks for putting it together. My only feedback right now relates to a couple typos / formatting changes that would be beneficial (particularly the intended nested list in the list of non goals). The user stories defined here are great, and align well with discussions we've been having (and work that's been done!).
On the topic of formatting, could we wrap lines at 80 characters when it makes sense? It makes it easier for reviewers to cite specific portions of the content, and minimize diff churn on updates (this text is taken from some of the embedded guidance in the doc).
I use the Rewrap VSCode extension to help with this. Also, the Markdown All in One extension would allow you to view a preview of the rendered markdown before committing.
scotwells
left a comment
scotwells
left a comment
There was a problem hiding this comment.
Great start! 🚀
I added some feedback mainly around nomenclature. As I was reading through the document I was originally thinking that the concept of a "Team" was aligned with our definition of an "Organization" but as I got deeper into the document (towards the RBAC/Audit logging section) it seems like the term may have changed to mean a grouping of users within an organization.
| #### Single Sign On (SSO) | ||
|
|
||
| Single Sign On (SSO) allows our customers to manage their team’s users outside of our built-in user database. SSO centralizes the database of users into a single service that controls authorization to all accounts and applications. | ||
|
|
||
| Enterprises use a large number of services with a large number of end users. It is nearly impossible to manage hundreds, thousands or tens of thousands of users across tens or hundreds of different applications. For this reason, enterprises have been using Single Sign On (or directory services) to manage the provisioning, deprovisioning and permissioning of accounts and privileges for many years. |
There was a problem hiding this comment.
There's a few different approaches that enterprises use to handle SSO (SAML, OIDC, SCIM, etc). Do we want to call out which ones we plan to support or should we direct the user to the other enhancement for that information?
There was a problem hiding this comment.
I think we should defer to the authentication enhancement. We could remove this paragraph entirely for clarity.
| #### Team Management | ||
|
|
||
| Teams describes the functionality that enables modern software to be collaborative and managed. Through Teams, users invite others to collaborative in application by creating or linking an account. Apps that don’t have team functionality often require password sharing for multiple users to access the account, which is an obvious security hurdle for most business users. |
There was a problem hiding this comment.
Can we adjust the nomenclature on "Team" to align with the term "Organization" we've adopted? As I was reading through this I realized this wasn't talking about introducing a new concept called a "Team" but was actually detailing us adding support for adding users to an organization.
There was a problem hiding this comment.
Would some of the functionality expected for typical teams be aligned more with IAM Groups, where users would be able to align external group membership with IAM Groups?
This would be similar to the concept of a Team in GitHub when you sync groups from AD - you specify a list of AD groups that should be a part of the team.
There was a problem hiding this comment.
I think having the concept of Groups makes sense, especially since we’re thinking of supporting SCIM which has the concepts of users and groups.
As I got further into the document it felt like Team was closer aligned with a Group than an organization but wasn’t 100% sure.
There was a problem hiding this comment.
I would assume an Organization (Datum Nomenclature) would have multiple Projects (Datum Nomenclature) which may want to have different sets of permissions applied to different users. So:
- Multiple people need to be invited to an Organization to participate.
- Once invited, permissions need to be applied.
- For convenience, a grouping of permissions across one or more projects could be applied across a group of users.
For the "group of users", what is the appropriate term? Whatever that term it, I think that is our interpretation of a "Team." Let me know and I can update the enhancement accordingly.
| - Invite - emails sent to users to invite them to the team. Invites are accepted or declined. | ||
| - List - users should be able to view the team, see pending invites and resend invitations. | ||
| - Remove - users can be removed from teams and logged out of current sessions related to that team. | ||
| - Resource discovery - users can find other users and resources created by those users easily. |
There was a problem hiding this comment.
Can you help me understand the overlap between this and projects?
As I see it, a user would be invited to an organization and granted access to one or more projects, but they should not be able to discover resources that they do not have access to within the organization.
There was a problem hiding this comment.
This item is a copy/paste from EnterpriseReady.io, and it seems a bit ambiguous. I think the point is that if a resource is viewable by a group/team, or viewable across the organization, it should be discoverable. I can try to clarify this point, or remove it from the enhancement entirely. Thoughts?
| Key elements for teams being applied to Datum Cloud Projects | ||
| - Add Permissions - It should be easy to assign permissions for a Datum Cloud project to a team | ||
| - View Permissions - Allow team members to view the permissions for an associated project. | ||
| - Remove Permissions - Allow administrators to remove permissions for a team from an associated project. |
There was a problem hiding this comment.
Can we adjust this to align with the policy based RBAC system we've defined?
I also want to call out that only users with IAM access to an organization or a project would be able to see who has been granted access to resources.
It should be easy to assign permissions for a Datum Cloud project to a team
Does a "Team" here refer to an Organization or a grouping of users within an organization?
| - Remove Permissions - Allow administrators to remove permissions for a team from an associated project. | ||
|
|
||
| Possible advanced features for Teams: | ||
| - Ownership - resources are created by a single user and then shared with others. Ownership of a resource can be transferred to another user, including the bulk transfer of all owned resources when a user is deleted. |
There was a problem hiding this comment.
With the resource hierarchy we've defined for Datum Cloud, all resources will either be owned by an Organization or Project resource. This approach prevents users from owning resources directly and needing to handle resource migrations when a user leaves an organization. Instead, the ownership always remains with the organization or project.
We do plan to support migrating projects between organizations or folders in the future, but do not have plans to support resource migrations between two projects.
|
|
||
| Possible advanced features for Teams: | ||
| - Ownership - resources are created by a single user and then shared with others. Ownership of a resource can be transferred to another user, including the bulk transfer of all owned resources when a user is deleted. | ||
| - Sub-teams - for large companies a single team would become too unwieldy. Instead, these enterprises will require that they can create a federated account of multiple teams with different settings (but likely unified billing) for each. |
There was a problem hiding this comment.
I think this would be covered by us having support for Projects/Folders to organize access to resources. This would allow organizations to unify billing for resources or give them flexibility to use multiple billing accounts if they needed to handle more advanced use cases like billing organizational units differently.
Co-authored-by: Joshua Reese <[email protected]> Signed-off-by: Tom Daly <[email protected]>
Co-authored-by: Joshua Reese <[email protected]> Signed-off-by: Tom Daly <[email protected]>
Co-authored-by: Joshua Reese <[email protected]> Signed-off-by: Tom Daly <[email protected]>
No description provided.