All Round 2 Review Changes

source/auditing-logging.txt

@@ -23,34 +23,31 @@ Auditing
 ~~~~~~~~
 
 Available on ``M10+`` {+clusters+}, database auditing lets you track system 
-activity for deployments with
-multiple users. As an |service| administrator, you can:
-
-- Rely on default auditing settings in |service|. By default, |service|
-  performs database authentication auditing in ``M10+`` {+clusters+} to
-  record authentication events, including those pertaining to:
-
-  - database users
-  - source IP addresses
-  - timestamps for successful and failed attempts
-
-- :atlas:`Configure a JSON-formatted audit filter 
-  </database-auditing/#configure-a-custom-auditing-filter>` to
-  customize MongoDB auditing
-  and select the actions, database users, |service| roles, and |ldap| groups
-  that you want to audit. If you create a custom audit filter, you can
-  skip using the managed {+atlas-ui+} auditing filter builder and configure
-  your own tailored filter of event auditing. For a full list of
-  events you can configure for auditing, and for a list of examples,
-  see :manual:`MongoDB auditing </core/auditing>` and :atlas:`Example Auditing Filters 
-  </database-auditing/#example-auditing-filters>`.
-
-  You can :manual:`configure manual auditing </core/auditing>` of most of the
-  documented :manual:`system event actions </reference/audit-message/mongo/#audit-event-actions--details--and-results>`
-  in |service|. Granular MongoDB database auditing allows you to track
-  usage of all DDL (Data Definition Language), DML (Data Manipulation Language),
-  and DCL (Data Control Language) commands in detail. See also
-  :atlas:`Set up Database Auditing </database-auditing>`.
+activity for deployments with multiple users. By default, |service|
+performs database authentication auditing in ``M10+`` {+clusters+} to
+record authentication events, including those pertaining to:
+
+- database users
+- source IP address
+- timestamps for both successful and failed attempts
+
+As an |service| administrator, you can create a custom JSON audit filter in 
+MongoDB to precisely control what gets audited across your system. This approach 
+lets you specify exactly which actions, database users, and Atlas roles should 
+be monitored, giving you more granular control than the standard 
+Atlas UI filter builder.
+
+With manual auditing configuration, you can monitor almost all documented system 
+events in Atlas. The comprehensive database auditing capabilities provide detailed 
+tracking of DDL (Data Definition Language), DML (Data Manipulation Language), 
+and DCL (Data Control Language) operations, providing complete visibility into 
+database schema changes, data modifications, and permission adjustments.
+
+For implementation guidance, including complete event lists and practical 
+configuration examples, refer to the :manual:`MongoDB auditing </core/auditing>` 
+and :atlas:`Example Auditing Filters </database-auditing/#example-auditing-filters>` 
+documentation. Additional setup instructions are available in the 
+:atlas:`Set up Database Auditing </database-auditing>`.
 
 .. _accessing-audit-logs:
 

source/auth.txt

@@ -20,9 +20,9 @@ Guidance for {+service+} Authorization and Authentication
    :class: onecol
 
 Authentication is the process of verifying the identity of a user.
-|service| requires all users to authenticate themselves in order 
-to determine their access. Authorization is the process of assigning 
-permissions to an authenticated user.
+Authorization is the process of assigning permissions to an authenticated user.
+|service| uses a deny-by-default security model. Users and machine accounts 
+must authenticate and be assigned permissions before they can access any resources.
 
 For :ref:`Authentication <arch-center-authentication-recs>`, |service| 
 provides robust authentication mechanisms that seamlessly integrate with your 
@@ -31,12 +31,13 @@ existing identity systems, providing secure access to the UI, database, and
 
 For :ref:`Authorization <arch-center-authorization-recs>`, |service| 
 provides Role-Based Access Control (RBAC) to govern 
-access to |service|. You must grant a user one or more roles that determine the
-user's access to database resources and operations. Outside of role
-assignments, the user has no access to the system.
+access to |service|. You must grant a user one or more roles to determine the
+user's access resources and operations. Outside of role assignments, the user 
+has no access to the system.
 
 .. toctree::
    :titlesonly:
 
    Authentication </auth/authentication>
    Authorization </auth/authorization>
+   Auth Examples </auth/auth-examples>

source/auth/auth-examples.txt

@@ -0,0 +1,193 @@
+.. _arch-center-examples:
+
+=========================================
+Authorization and Authentication Examples
+=========================================
+
+.. default-domain:: mongodb
+
+.. facet::
+   :name: genre
+   :values: reference
+
+.. meta:   
+   :description: Learn about the different authorization and authentication mechanisms that Atlas supports.
+
+.. contents:: On this page
+   :local:
+   :backlinks: none
+   :depth: 2
+   :class: onecol
+
+
+The following examples show how to implement our recommendations for authentication 
+and authorization for different access types. The examples show how to implement 
+the recommendations using both the |service| CLI and Terraform.
+
+To learn about Terraform, see :ref:`getting-started-terraform` and the
+`MongoDB Atlas Provider Terraform docs <https://registry.terraform.io/providers/mongodb/mongodbatlas/latest/docs>`__. 
+
+.. tabs::
+
+   .. tab:: CLI
+      :tabid: cli
+
+      |service| UI
+      ~~~~~~~~~~~~
+
+      For access to the |service| UI:
+
+      - Implement :atlas:`{+ip-access-list+}s </security/ip-access-list/>`. 
+        For example, 
+
+        .. code-block::
+
+           atlas organizations apiKeys accessLists create --apiKey <API_KEY_ID> --ip <IP_ADDRESS>
+
+      - Implement :ref:`Federated Authentication <arch-center-federated_auth>` or 
+        |service| credentials and :ref:`Multi-factor Authentication (MFA) <arch-center-mfa>`.
+
+        To set up Federated Auth, use the 
+        :atlas:`atlas-federatedAuthentication </command/atlas-federatedAuthentication/>` 
+        and related commands. You can then use the :atlas:`atlas-users-invite </command/atlas-users-invite/>` 
+        command to invite users to your organization and projects.
+
+        To get started, use the following command: 
+
+        .. code-block::
+
+           atlas federatedAuthentication --help
+
+        .. note::
+
+           For users that authenticate with SSO, you will also need to configure 
+           the SSO Identity Provider. 
+
+        For more information, see :ref:`atlas-federated-authentication`.
+
+      Database Access
+      ~~~~~~~~~~~~~~~
+
+      Workforce (Human) Access
+      `````````````````````````
+
+      For workforce database access:
+
+      - Use :atlas:`Workforce Identity Federation </workforce-oidc/>`.
+
+      - Use the :atlascli:`atlas-dbusers-certs-create <command/atlas-dbusers-certs-create>`
+        command to create Atlas-managed MFA (Multi-Factor Authentication)
+        :atlas:`X.509 client </security-self-managed-x509>`  certificates.
+
+        .. note::
+
+           To use self-managed certificates, you must first configure 
+           :atlas:`X.509 </operator/v2.7/ak8so-x509/>`:
+
+           .. code-block::
+
+              atlas dbusers certs create --username <USERNAME> --projectId <PROJECT_ID> [--monthsUntilExpiration <MONTHS>] [--output json]
+
+
+      Workload (Machine) Access
+      `````````````````````````
+
+      For workload (machine) access, use :atlas:`Workload Identity Federation </workload-oidc/>`.
+
+
+      API Access
+      ~~~~~~~~~~
+
+      Use the :atlas:`serviceAccounts </command/atlas-api-serviceAccounts/>` 
+      and related commands to create and manage Service Accounts.
+      For example, 
+
+      .. code-block:: shell
+
+         atlas api serviceAccounts createServiceAccount [options]
+
+      For development and test environments, you can also use 
+      :atlas:`API keys </command/atlas-projects-apikeys-create/>`. For example, 
+
+      .. code-block:: shell
+
+         atlas organizations apiKeys create [options]
+
+
+   .. tab:: Terraform
+      :tabid: Terraform
+
+      The following examples demonstrate how to configure
+      authentication and authorization. Before you can create
+      resources with Terraform, you must: 
+
+      - :ref:`Create your paying organization <configure-paying-org>` and 
+        :ref:`create an API key <atlas-admin-api-access>` for the paying 
+        organization. Store your API key as environment variables by running the
+        following command in the terminal: 
+
+        .. code-block::
+
+           export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
+           export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
+
+      - `Install Terraform <https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli>`__
+
+      Common Files 
+      ~~~~~~~~~~~~
+
+      You must create the following files for each example. Place
+      the files for each example in their own directory. Change
+      the IDs and names to use your values. Then run the commands
+      to initialize Terraform, view the Terraform plan, and apply
+      the changes. 
+
+      azure.tf 
+      ````````
+
+      .. include:: /includes/examples/terraform/tf-example-auth-tfazure.rst
+
+      variables.tf 
+      ````````````
+
+      .. include:: /includes/examples/terraform/staging-prod/tf-example-auth-variables-stagingprod.rst
+
+      terraform.tfvars 
+      ````````````````
+      .. include:: /includes/examples/terraform/staging-prod/tf-example-auth-tfvars-stagingprod.rst
+
+      outputs.tf 
+      ``````````
+
+      .. include:: /includes/examples/terraform/staging-prod/tf-example-auth-tfoutputs-stagingprod.rst
+
+      Configure Federated Settings for Identity Provider 
+      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+      Use the following to set up an :abbr:`OIDC (OpenID Connect)`
+      federated identity provider in |service|, for using it with
+      |azure|. It allows access by using OIDC tokens issued by |azure|
+      Active Directory. 
+
+      .. include:: /includes/examples/terraform/staging-prod/tf-example-auth-oidc-stagingprod.rst
+
+      Use the following to create an :abbr:`OIDC (OpenID Connect)`
+      federated authentication user. 
+
+      .. include:: /includes/examples/terraform/staging-prod/tf-example-auth-create-oidc-user-stagingprod.rst
+
+      Configure Custom Role 
+      ~~~~~~~~~~~~~~~~~~~~~
+
+      Use the following to create a custom role named ``my_custom_role``
+      which allows update, add, and delete operations on any collection
+      in the database named ``myDb``.
+
+      .. include:: /includes/examples/terraform/staging-prod/tf-example-auth-create-custom-role-stagingprod.rst
+
+
+.. include:: /includes/complete-examples-terraform.rst 
+
+
+For an example of an |service| project with the |service| role assigned
+to a specific group, see :ref:`Examples <arch-center-hierarchy>`.