[DOCS-5959] Document how to import an authenticated deployment into automation Created: 03/Aug/15  Updated: 13/May/16  Resolved: 26/Aug/15

Status: Closed
Project: Documentation
Component/s: Cloud Manager
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: Andrew Davidson Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 0
Labels: collector-298ba4e7
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Location: https://docs.opsmanager.mongodb.com/current/tutorial/add-existing-host-to-automation/
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 Safari/537.36
Referrer: https://docs.opsmanager.mongodb.com/current/search/?query=mms-automation
Screen Resolution: 1920 x 1080
repo: REPONAME
source: tutorial/add-existing-host-to-automation


Issue Links:
Related
is related to DOCS-7861 Document how to import a deployment w... Closed
Participants:
Days since reply: 8 years, 25 weeks ago

 Description   

It is critical that we explain in "import" documentation how auth is handled.

For example this blog post contains more information http://blog.cloud.mongodb.com/post/111860709590/introduction-to-import-existing-deployment-for in the sense that it is shown that you would need to pre-create an Automation agent user to grant the Automation agent permissions on the attached-to cluster.

Importing a cluster with Auth enabled is a complicated operation:
1) The system will try to bring in all the users / roles in that cluster. Note that if there are other clusters managed in the deployment, these users / roles will be added to the other clusters (not always wanted --> the work-around is to use a separate group whenever different clusters will have a different auth profile.

2) If a Group's Deployment already has an authentication profile enabled (e.g. isn't in a completely blank fresh state) then attached-to processes will require the mms-automation user be pre-created on them with appropriate permissions and password based on what the Automation agent expects (e.g. if "Mongodb-CR" is used then *Manager will have pre-created a random password for the mms-automation user which can be found in the Automation configuration for the Group's Deployment".

3) Note that a Group's Deployment can have authentication enabled even if there are no managed MongoDB processes (e.g. an empty deployment) which is a particularly awkward context to be unable to attach to a cluster that doesn't have the precisely correct user created yet.

Separately, attaching to an auth-enabled cluster where the Group's Deployment doesn't yet have "auth" enabled will cause the auth settings from the new deployment to be mimic'd in the Deployment. This is handy and we should point it out.

In an ideal world, when attaching to a cluster with auth enabled:
1) Create mms-automation user on cluster
2) Create new fresh / clean Group
3) Import the cluster into this new group.



 Comments   
Comment by Githook User [ 26/Aug/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5959 remove a prereq from add monitored deployment to automation page
Branch: master
https://github.com/10gen/mms-docs/commit/ca844adff72f0885a94a9cd4f6284006935eadf8

Comment by Githook User [ 26/Aug/15 ]

Author:

{u'username': u'kay-kim', u'name': u'kay', u'email': u'kay.kim@10gen.com'}

Message: DOCS-5959 add access control considerations to import to automation tutorial
Branch: v1.8
https://github.com/10gen/mms-docs/commit/91fd9a50b1c4a24d4d659b7845701799fcd81919

Generated at Thu Feb 08 07:51:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.