Replace Admonition Style (#1092)

Co-authored-by: Erik Osterman (CEO @ Cloud Posse) <[email protected]>

Author: milldr

deprecated/eks/karpenter-provisioner/README.md

@@ -1,13 +1,13 @@
 # Component: `eks/karpenter-provisioner`
 
-:::warning This component is DEPRECATED
-
-With v1beta1 of Karpenter, the `provisioner` component is deprecated.
-Please use the `eks/karpenter-node-group` component instead.
-
-For more details, see the [Karpenter v1beta1 release notes](/modules/eks/karpenter/CHANGELOG.md).
-
-:::
+> [!WARNING]
+>
+> #### This component is DEPRECATED
+>
+> With v1beta1 of Karpenter, the `provisioner` component is deprecated.
+> Please use the `eks/karpenter-node-group` component instead.
+>
+> For more details, see the [Karpenter v1beta1 release notes](/modules/eks/karpenter/CHANGELOG.md).
 
 This component deploys [Karpenter provisioners](https://karpenter.sh/v0.18.0/aws/provisioning) on an EKS cluster.
 

modules/account/README.md

@@ -4,13 +4,11 @@ This component is responsible for provisioning the full account hierarchy along
 includes the ability to associate Service Control Policies (SCPs) to the Organization, each Organizational Unit and
 account.
 
-:::info
-
-Part of a
-[cold start](https://docs.cloudposse.com/reference-architecture/how-to-guides/implementation/enterprise/implement-aws-cold-start)
-so it has to be initially run with `SuperAdmin` role.
-
-:::
+> [!NOTE]
+>
+> Part of a
+> [cold start](https://docs.cloudposse.com/reference-architecture/how-to-guides/implementation/enterprise/implement-aws-cold-start)
+> so it has to be initially run with `SuperAdmin` role.
 
 In addition, it enables
 [AWS IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html), which helps
@@ -178,15 +176,13 @@ SuperAdmin) credentials you have saved in 1Password.
 
 #### Request an increase in the maximum number of accounts allowed
 
-:::caution
-
-Make sure your support plan for the _root_ account was upgraded to the "Business" level (or Higher). This is necessary
-to expedite the quota increase requests, which could take several days on a basic support plan. Without it, AWS support
-will claim that since we’re not currently utilizing any of the resources, so they do not want to approve the requests.
-AWS support is not aware of your other organization. If AWS still gives you problems, please escalate to your AWS TAM.
-See [AWS](https://docs.cloudposse.com/reference-architecture/reference/aws).
-
-:::
+> [!WARNING]
+>
+> Make sure your support plan for the _root_ account was upgraded to the "Business" level (or Higher). This is necessary
+> to expedite the quota increase requests, which could take several days on a basic support plan. Without it, AWS
+> support will claim that since we’re not currently utilizing any of the resources, so they do not want to approve the
+> requests. AWS support is not aware of your other organization. If AWS still gives you problems, please escalate to
+> your AWS TAM. See [AWS](https://docs.cloudposse.com/reference-architecture/reference/aws).
 
 1. From the region list, select "US East (N. Virginia) us-east-1".
 
@@ -318,21 +314,19 @@ atmos terraform import account --stack core-gbl-root 'aws_organizations_organiza
 AWS accounts and organizational units are generated dynamically by the `terraform/account` component using the
 configuration in the `gbl-root` stack.
 
-:::info _**Special note:**_
-
-In the rare case where you will need to be enabling non-default AWS Regions, temporarily comment out the
-`DenyRootAccountAccess` service control policy setting in `gbl-root.yaml`. You will restore it later, after enabling the
-optional Regions. See related:
-[Decide on Opting Into Non-default Regions](https://docs.cloudposse.com/reference-architecture/design-decisions/cold-start/decide-on-opting-into-non-default-regions)
-
-:::
-
-:::caution You must wait until your quota increase request has been granted
-
-If you try to create the accounts before the quota increase is granted, you can expect to see failures like
-`ACCOUNT_NUMBER_LIMIT_EXCEEDED`.
-
-:::
+> [!IMPORTANT]
+>
+> In the rare case where you will need to be enabling non-default AWS Regions, temporarily comment out the
+> `DenyRootAccountAccess` service control policy setting in `gbl-root.yaml`. You will restore it later, after enabling
+> the optional Regions. See related:
+> [Decide on Opting Into Non-default Regions](https://docs.cloudposse.com/reference-architecture/design-decisions/cold-start/decide-on-opting-into-non-default-regions)
+
+> [!TIP]
+>
+> #### You must wait until your quota increase request has been granted
+>
+> If you try to create the accounts before the quota increase is granted, you can expect to see failures like
+> `ACCOUNT_NUMBER_LIMIT_EXCEEDED`.
 
 In the Geodesic shell, execute the following commands to provision AWS Organizational Units and AWS accounts:
 

modules/auth0/tenant/README.md

@@ -42,11 +42,11 @@ in Terraform. Follow the
 [Auth0 provider documentation](https://registry.terraform.io/providers/auth0/auth0/latest/docs/guides/quickstart) to
 create a Machine to Machine application.
 
-:::tip Machine to Machine App Name
-
-Use the Context Label format for the machine name for consistency. For example, `acme-plat-gbl-prod-auth0-provider`.
-
-:::
+> [!TIP]
+>
+> #### Machine to Machine App Name
+>
+> Use the Context Label format for the machine name for consistency. For example, `acme-plat-gbl-prod-auth0-provider`.
 
 After creating the Machine to Machine application, add the app's domain, client ID, and client secret to AWS Systems
 Manager Parameter Store in the same account and region as this component deployment. The path for the parameters are

modules/aws-config/README.md

@@ -20,25 +20,25 @@ Some of the key features of AWS Config include:
 - Notifications and alerts: AWS Config can send notifications and alerts when changes are made to your AWS resources
   that could impact their compliance or security posture.
 
-:::caution AWS Config Limitations
-
-You'll also want to be aware of some limitations with AWS Config:
-
-- The maximum number of AWS Config rules that can be evaluated in a single account is 1000.
-  - This can be mitigated by removing rules that are duplicated across packs. You'll have to manually search for these
-    duplicates.
-  - You can also look for rules that do not apply to any resources and remove those. You'll have to manually click
-    through rules in the AWS Config interface to see which rules are not being evaluated.
-  - If you end up still needing more than 1000 rules, one recommendation is to only run packs on a schedule with a
-    lambda that removes the pack after results are collected. If you had different schedule for each day of the week,
-    that would mean 7000 rules over the week. The aggregators would not be able to handle this, so you would need to
-    make sure to store them somewhere else (i.e. S3) so the findings are not lost.
-  - See the
-    [Audit Manager docs](https://aws.amazon.com/blogs/mt/integrate-across-the-three-lines-model-part-2-transform-aws-config-conformance-packs-into-aws-audit-manager-assessments/)
-    if you think you would like to convert conformance packs to custom Audit Manager assessments.
-- The maximum number of AWS Config conformance packs that can be created in a single account is 50.
-
-:::
+> [!WARNING]
+>
+> #### AWS Config Limitations
+>
+> You'll also want to be aware of some limitations with AWS Config:
+>
+> - The maximum number of AWS Config rules that can be evaluated in a single account is 1000.
+>   - This can be mitigated by removing rules that are duplicated across packs. You'll have to manually search for these
+>     duplicates.
+>   - You can also look for rules that do not apply to any resources and remove those. You'll have to manually click
+>     through rules in the AWS Config interface to see which rules are not being evaluated.
+>   - If you end up still needing more than 1000 rules, one recommendation is to only run packs on a schedule with a
+>     lambda that removes the pack after results are collected. If you had different schedule for each day of the week,
+>     that would mean 7000 rules over the week. The aggregators would not be able to handle this, so you would need to
+>     make sure to store them somewhere else (i.e. S3) so the findings are not lost.
+>   - See the
+>     [Audit Manager docs](https://aws.amazon.com/blogs/mt/integrate-across-the-three-lines-model-part-2-transform-aws-config-conformance-packs-into-aws-audit-manager-assessments/)
+>     if you think you would like to convert conformance packs to custom Audit Manager assessments.
+> - The maximum number of AWS Config conformance packs that can be created in a single account is 50.
 
 Overall, AWS Config provides you with a powerful toolset to help you monitor and manage the configurations of your AWS
 resources, ensuring that they remain compliant, secure, and properly configured over time.
@@ -79,21 +79,22 @@ Before deploying this AWS Config component `config-bucket` and `cloudtrail-bucke
 This component has a `default_scope` variable for configuring if it will be an organization-wide or account-level
 component by default. Note that this can be overridden by the `scope` variable in the `conformance_packs` items.
 
-:::info Using the account default_scope
-
-If default_scope == `account`, AWS Config is regional AWS service, so this component needs to be deployed to all
-regions. If an individual `conformance_packs` item has `scope` set to `organization`, that particular pack will be
-deployed to the organization level.
-
-:::
-
-:::info Using the organization default_scope
-
-If default_scope == `organization`, AWS Config is global unless overriden in the `conformance_packs` items. You will
-need to update your org to allow the `config-multiaccountsetup.amazonaws.com` service access principal for this to work.
-If you are using our `account` component, just add that principal to the `aws_service_access_principals` variable.
-
-:::
+> [!TIP]
+>
+> #### Using the account default_scope
+>
+> If default_scope == `account`, AWS Config is regional AWS service, so this component needs to be deployed to all
+> regions. If an individual `conformance_packs` item has `scope` set to `organization`, that particular pack will be
+> deployed to the organization level.
+
+> [!TIP]
+>
+> #### Using the organization default_scope
+>
+> If default_scope == `organization`, AWS Config is global unless overriden in the `conformance_packs` items. You will
+> need to update your org to allow the `config-multiaccountsetup.amazonaws.com` service access principal for this to
+> work. If you are using our `account` component, just add that principal to the `aws_service_access_principals`
+> variable.
 
 At the AWS Organizational level, the Components designate an account to be the `central collection account` and a single
 region to be the `central collection region` so that compliance information can be aggregated into a central location.

modules/aws-sso/README.md

@@ -32,14 +32,12 @@ recommended `gbl-root` stack.
 
 ### Google Workspace
 
-:::important
-
-> Your identity source is currently configured as 'External identity provider'. To add new groups or edit their
-> memberships, you must do this using your external identity provider.
-
-Groups _cannot_ be created with ClickOps in the AWS console and instead must be created with AWS API.
-
-:::
+> [!IMPORTANT]
+>
+> > Your identity source is currently configured as 'External identity provider'. To add new groups or edit their
+> > memberships, you must do this using your external identity provider.
+>
+> Groups _cannot_ be created with ClickOps in the AWS console and instead must be created with AWS API.
 
 Google Workspace is now supported by AWS Identity Center, but Group creation is not automatically handled. After
 [configuring SAML and SCIM with Google Workspace and IAM Identity Center following the AWS documentation](https://docs.aws.amazon.com/singlesignon/latest/userguide/gs-gwp.html),

modules/dns-primary/README.md

@@ -93,12 +93,10 @@ components:
                 YourVeryLongStringGoesHere
 ```
 
-:::info
-
-Use the [acm](https://docs.cloudposse.com/components/library/aws/acm) component for more advanced certificate
-requirements.
-
-:::
+> [!TIP]
+>
+> Use the [acm](https://docs.cloudposse.com/components/library/aws/acm) component for more advanced certificate
+> requirements.
 
 <!-- prettier-ignore-start -->
 <!-- BEGINNING OF PRE-COMMIT-TERRAFORM DOCS HOOK -->

modules/ecr/README.md

@@ -6,12 +6,10 @@ This utilizes
 to assign accounts to various roles. It is also compatible with the
 [GitHub Actions IAM Role mixin](https://github.com/cloudposse/terraform-aws-components/blob/master/mixins/github-actions-iam-role/README-github-action-iam-role.md).
 
-:::caution
-
-Older versions of our reference architecture have an`eks-iam` component that needs to be updated to provide sufficient
-IAM roles to allow pods to pull from ECR repos
-
-:::
+> [!WARNING]
+>
+> Older versions of our reference architecture have an`eks-iam` component that needs to be updated to provide sufficient
+> IAM roles to allow pods to pull from ECR repos
 
 ## Usage
 

modules/eks/actions-runner-controller/CHANGELOG.md

@@ -76,12 +76,12 @@ of memory allocated to the runner Pod to account for this. This is generally not
 small enough amount of disk space that it can be reasonably stored in the RAM allocated to a single CPU in an EC2
 instance, so it is the CPU that remains the limiting factor in how many Runners can be run on an instance.
 
-:::warning You must configure a memory request for the runner Pod
-
-When using `tmpfs_enabled`, you must configure a memory request for the runner Pod. If you do not, a single Pod would be
-allowed to consume half the Node's memory just for its disk storage.
-
-:::
+> [!WARNING]
+>
+> #### You must configure a memory request for the runner Pod
+>
+> When using `tmpfs_enabled`, you must configure a memory request for the runner Pod. If you do not, a single Pod would
+> be allowed to consume half the Node's memory just for its disk storage.
 
 #### Configure startup timeout via `wait_for_docker_seconds`
 

modules/eks/cluster/CHANGELOG.md

@@ -49,13 +49,13 @@ Components PR [#1033](https://github.com/cloudposse/terraform-aws-components/pul
 
 ### Major Breaking Changes
 
-:::warning Major Breaking Changes, Manual Intervention Required
-
-This release includes a major breaking change that requires manual intervention to migrate existing clusters. The change
-is necessary to support the new AWS Access Control API, which is more secure and more reliable than the old `aws-auth`
-ConfigMap.
-
-:::
+> [!WARNING]
+>
+> #### Major Breaking Changes, Manual Intervention Required
+>
+> This release includes a major breaking change that requires manual intervention to migrate existing clusters. The
+> change is necessary to support the new AWS Access Control API, which is more secure and more reliable than the old
+> `aws-auth` ConfigMap.
 
 This release drops support for the `aws-auth` ConfigMap and switches to managing access control with the new AWS Access
 Control API. This change allows for more secure and reliable access control, and removes the requirement that Terraform
@@ -65,18 +65,18 @@ In this release, this component only supports assigning "team roles" to Kubernet
 Access Policies is not yet implemented. However, if you specify `system:masters` as a group, that will be translated
 into assigning the `AmazonEKSClusterAdminPolicy` to the role. Any other `system:*` group will cause an error.
 
-:::tip Network Access Considerations
-
-Previously, this component required network access to the EKS control plane to manage the `aws-auth` ConfigMap. This
-meant having the EKS control plane accessible from the public internet, or using a bastion host or VPN to access the
-control plane. With the new AWS Access Control API, Terraform operations on the EKS cluster no longer require network
-access to the EKS control plane.
-
-This may seem like it makes it easier to secure the EKS control plane, but Terraform users will still require network
-access to the EKS control plane to manage any deployments or other Kubernetes resources in the cluster. This means that
-this upgrade does not substantially change the need for network access.
-
-:::
+> [!TIP]
+>
+> #### Network Access Considerations
+>
+> Previously, this component required network access to the EKS control plane to manage the `aws-auth` ConfigMap. This
+> meant having the EKS control plane accessible from the public internet, or using a bastion host or VPN to access the
+> control plane. With the new AWS Access Control API, Terraform operations on the EKS cluster no longer require network
+> access to the EKS control plane.
+>
+> This may seem like it makes it easier to secure the EKS control plane, but Terraform users will still require network
+> access to the EKS control plane to manage any deployments or other Kubernetes resources in the cluster. This means
+> that this upgrade does not substantially change the need for network access.
 
 ### Minor Changes
 
@@ -94,12 +94,10 @@ Full details of the migration process can be found in the `cloudposse/terraform-
 [migration document](https://github.com/cloudposse/terraform-aws-eks-cluster/blob/main/docs/migration-v3-v4.md). This
 section is a streamlined version for users of this `eks/cluster` component.
 
-:::important
-
-The commands below assume the component is named "eks/cluster". If you are using a different name, replace "eks/cluster"
-with the correct component name.
-
-:::
+> [!IMPORTANT]
+>
+> The commands below assume the component is named "eks/cluster". If you are using a different name, replace
+> "eks/cluster" with the correct component name.
 
 #### Prepare for Migration