You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: source/auth.txt
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -258,7 +258,7 @@ minimize the risk of unauthorized access:
258
258
259
259
- Follow best practices for
260
260
rotating |api| keys regularly. To learn how to rotate these keys with
261
-
{+vault+}, see `the Hashicorp documentation <https://developer.hashicorp.com/vault/docs/secrets/mongodbatlas>`__.
261
+
{+vault+}, for example, see `the Hashicorp documentation <https://developer.hashicorp.com/vault/docs/secrets/mongodbatlas>`__.
262
262
263
263
- Use the IP access list for your API keys. To learn more, see
264
264
:atlas:`Require an IP Access List for the {+atlas-admin-api+} </configure-api-access/#optional--require-an-ip-access-list-for-the-atlas-administration-api>`.
Copy file name to clipboardExpand all lines: source/hierarchy.txt
+3-2Lines changed: 3 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -250,7 +250,8 @@ To learn more about parsing billing data using tags, see
250
250
251
251
In a dedicated deployment ({+cluster+} size ``M10``\+), {+service+}
252
252
allocates resources exclusively. We recommend dedicated deployments
253
-
because they provide high security and performance.
253
+
because they provide higher security and performance than shared
254
+
clusters.
254
255
255
256
Use the following {+cluster+} size guide to select a {+cluster+} tier that ensures performance without over-provisioning. The {+cluster+} size guide also provides recommendations on which {+cluster+} tiers
256
257
are suitable for development and testing environments, and which are
@@ -292,7 +293,7 @@ the {+cluster+} resources required by using your organization's approximate data
Copy file name to clipboardExpand all lines: source/landing-zone.txt
+10-6Lines changed: 10 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -48,10 +48,11 @@ pre-configured cloud environment for {+service+} that conforms to your organizat
48
48
move workloads to the cloud, and it is often provisioned
49
49
programmatically using an API or tools like Terraform.
50
50
51
-
An {+service+} landing zone defines the default and minimum settings
52
-
that teams use to deploy workloads in {+service+}. A landing zone also
53
-
defines the tools and settings that teams should leverage in order to
54
-
integrate systems with {+service+} and their applications connecting to {+service+}.
51
+
An {+service+} landing zone defines the default, minimum, and maximum
52
+
settings that teams use to deploy workloads in {+service+}. A landing
53
+
zone also defines the tools and settings that teams should leverage in
54
+
order to integrate systems with {+service+} and their applications
55
+
connecting to {+service+}.
55
56
56
57
Why Do You Need a Landing Zone?
57
58
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -82,13 +83,16 @@ requirements when you create a landing zone:
82
83
* - System Hierarchy Requirements
83
84
- Identify how you will group database {+clusters+} for management
84
85
and isolation. For example, clarify how your team should arrange
85
-
{+service+} projects or {+service+} organizations.
86
+
{+service+} organizations, projects, and {+clusters+}.
86
87
87
88
To get recommendations and learn more about this topic, see
88
89
:ref:`arch-center-hierarchy`.
89
90
* - Access Controls
90
91
- Identify MongoDB {+service+} Control Plane access controls, and
91
-
database access controls for both workload and workforce principals. Create a comprehensive list of principals and mechanisms for how you will authenticate and authorize. Define {+service+} API key access controls, including authorizations and expiration rules.
92
+
database access controls for both workload and workforce principals. Create a comprehensive list of principals and mechanisms for how you will authenticate and authorize. Define {+service+} API key policies, including authorizations and internal policies for key rotation.
93
+
94
+
To get recommendations and learn more about this topic, see
95
+
:ref:`arch-center-auth`.
92
96
* - Change Control and Auditability Requirements
93
97
- Clarify any change control or audit controls requirements. This
94
98
can include change approval processes and tools, along with
0 commit comments