search

mongodb / atlas-osb

Deprecated project, please see https://github.com/mongodb/helm-charts for your best starting place
Apache License 2.0
7 stars 7 forks source link

# Create ability for users to be added to Atlas Projects #25

Closed jasonmimick closed 4 years ago

jasonmimick commented 4 years ago

Original request: 00685888: I want to invite a user via the API (MongoDB Internal)

Since the broker plans provision complete deployments, cluster admin need a was to add their users to be able to access these new Projects in Atlas. This ask is to consider how the broker could provide the functionality for cluster administrator to be able to offer a service which can add users to Atlas Projects.

I figured out a workflow and the corresponding APIs that will work. If we can add some command in the broker to update-service to add a user, here’s what the workflow would look like:

1) User calls broker command (maybe update service?). They input: firstName, lastName, emailAddress

2) The broker checks if the user already exists: GET https://cloud.mongodb.com/api/atlas/v1.0/users/byName/{{emailAddress}}

If user doesn’t exist, the response looks like below. 200 response. Have the broker store the user ID to be used afterwards.

{
    "country": "CA",
    "emailAddress": "john.jw.tan@gmail.com",
    "firstName": "John",
    "id": "5f5e82412c8f4b7b43bc0fca",
    "lastName": "Tan",
    "links": [
        {
            "href": "https://cloud.mongodb.com/api/atlas/v1.0/users/5f5e82412c8f4b7b43bc0fca",
            "rel": "self"
        },
        {
            "href": "https://cloud.mongodb.com/api/atlas/v1.0/users/5f5e82412c8f4b7b43bc0fca/whitelist",
            "rel": "http://mms.mongodb.com/whitelist"
        }
    ],
    "roles": [
        {
            "orgId": "5f05c2ff6fa98c1ed3d2356a",
            "roleName": "ORG_MEMBER"
        },
        {
            "groupId": "5f47d83d6d8c874ca7dc9166",
            "roleName": "GROUP_OWNER"
        }    ],
    "teamIds": [],
    "username": "john.jw.tan@gmail.com"
}

3) if the user doesn’t exist, the response is a 401.

{
    "detail": "The currently logged in user does not have the user administrator role for any group, team, or organization containing user john.jw.tan@gmail.com2.",
    "error": 401,
    "errorCode": "NOT_USER_ADMIN",
    "parameters": [
        "john.jw.tan@gmail.com2"
    ],
    "reason": "Unauthorized"
}

4) If user exists, use the API to add user to the project: PATCH https://cloud.mongodb.com/api/atlas/v1.0/users/{{userID}} Payload

{
    "roles" : [
    {
        "groupId" : "5f47d83d6d8c874ca7dc9166",
        "roleName" : "GROUP_OWNER"
    }
    ]
}

5) If user doesn’t exist, use the API to create new user and add them to the project: POST https://cloud.mongodb.com/api/atlas/v1.0/users/

Payload

{
  "username" : "{{user email input }}",
  "password" : "{{any default password, maybe store in keys credhub file? , user will request password reset to access}}",
  "emailAddress" : "{{user email input }}",
  "mobileNumber" : "",
  "firstName" : "{{first name user input}}",
  "lastName" : "{{last name user input}}",
  "roles" : [
    {
    "groupId" : "{{project name{{",
    "roleName" : "GROUP_OWNER"
    }
  ],
  "country" : "CA {{maybe something to put into keys credhub file}}"
}

--- end of initial request ---

Proposed Solution

Add support to the existing Plan type to support adding/removing users from Atlas projects along with the "service plan instance" life cycle.

We would add a new field to each plan called atlasUser. This allows consumers to pass along their information during cf create-service for the corresponding Atlas API calls to add the user to the project.

Additional users can be added or removed from the Atlas project through an extension of the update-service operation. For example, first Developer1 would run this command to just create a plan (Project, Cluster, DBUser, IPWhitelist):

cf create-service atlas basic-plan myatlasdb -c '{ "email" : "dev1@acme.com", ...}'

This would create the entire plan and add the user to the Atlas project. Now, when junior Developer2 needs access, how can they accomplish that themselves?

We will add a feature to update-service to support this. So Developer1 just runs, 

cf update-service myatlasdb dev2 -c '{ "op" : "AddUserToProject", "email" : "dev2@acme.com", "password" : "ChangeMe!", ...}'

In this case, Developer1 would set the password, instructing Dev2 to change it right away when the login. Note - the admin should document and understand this procedure for security implication, as the broker cannot control these passwords.

Removing users is similar, 

cf update-service myatlasdb dev2 -c '{ "op" : "RemoveUserFromProject", "email" : "dev2@acme.com", ...}'

Users do not need to be "AddUserToProject" added to be "RemoveUserFromProject" removed. Meaning, you can remove users from Atlas project with this command even if they were added through the Atlas UI. This is a simple controller and will not maintain ANY state of the list of users in an Atlas project.

Note that this functionality would not control all the users in the Atlas project. Meaning, this functionality is is basic "controller" - it allows create & delete on specific Atlas users in specific projects. Should you need full management, please see the Atlas UI or use the API directly.

Technical Notes

  1. Add atlasUsers to Plan
  2. Add logic to add/remove on provision/deprovision, add logic to handle bind/unbind
  3. Be sure to log appropriate and care to hide passwords.
jasonmimick commented 4 years ago

Questions:

  1. Can we "automatically" add the user who is calling cf create-service ... to the Atlas project that gets generated for the service being created? We would add parameters -c to capture the email, e.g. -c {"email" : "dev@manulife.com"}.

  2. Users will need to pass their passwords on the cf create-service ... call. Is this ok?

  3. What role should the user be assigned in Atlas? Here are the options: GROUP_OWNER - Project Owner GROUP_CLUSTER_MANAGER - Project Cluster Manager GROUP_READ_ONLY - Project Read Only GROUP_DATA_ACCESS_ADMIN - Project Data Access Admin GROUP_DATA_ACCESS_READ_WRITE - Project Data Access Read/Write GROUP_DATA_ACCESS_READ_ONLY - Project Data Access Read Only https://docs.atlas.mongodb.com/reference/api/user-create/

jasonmimick commented 4 years ago

Accepted Solution

Add support to the existing Plan type to support adding/removing users from Atlas projects along with the "service plan instance" life cycle.

We would add a new field to each plan called atlasUser. This allows consumers to pass along their information during cf create-service for the corresponding Atlas API calls to add the user to the project.

Additional users can be added or removed from the Atlas project through an extension of the update-service operation. For example, first Developer1 would run this command to just create a plan (Project, Cluster, DBUser, IPWhitelist):

cf create-service atlas basic-plan myatlasdb -c '{ "email" : "dev1@acme.com", ...}'

This would create the entire plan and add the user to the Atlas project. Now, when junior Developer2 needs access, how can they accomplish that themselves?

We will add a feature to update-service to support this. So Developer1 just runs, 

cf update-service myatlasdb dev2 -c '{ "op" : "AddUserToProject", "email" : "dev2@acme.com", "password" : "ChangeMe!", ...}'

In this case, Developer1 would set the password, instructing Dev2 to change it right away when the login. Note - the admin should document and understand this procedure for security implication, as the broker cannot control these passwords.

Removing users is similar, 

cf update-service myatlasdb dev2 -c '{ "op" : "RemoveUserFromProject", "email" : "dev2@acme.com", ...}'

Users do not need to be "AddUserToProject" added to be "RemoveUserFromProject" removed. Meaning, you can remove users from Atlas project with this command even if they were added through the Atlas UI. This is a simple controller and will not maintain ANY state of the list of users in an Atlas project.

Note that this functionality would not control all the users in the Atlas project. Meaning, this functionality is is basic "controller" - it allows create & delete on specific Atlas users in specific projects. Should you need full management, please see the Atlas UI or use the API directly.

Technical Notes