diff --git a/docs/discussions/knowledge-base/395.mdx b/docs/discussions/knowledge-base/395.mdx index ae191e7c68..0617e7d6cf 100644 --- a/docs/discussions/knowledge-base/395.mdx +++ b/docs/discussions/knowledge-base/395.mdx @@ -13,8 +13,8 @@ import GitHub from "/src/components/GitHub" Knowledge Base -

Trouble logging in to the Developer Portal

-\n

Tracked in ticket #108516

\n\n","bodyHTML":"

When I click the “Sign In” link it says the link is expired. I did it from the button and from copy/pasting the actual URL into the browser.

\n

What are next steps?

\n
\n\n

Tracked in ticket #108516

\n","answer":{"body":"Some email providers will pre-visit the link when you click on it, which can invalidate the token.\r\n\r\nTo remedy this:\r\n\r\n1. Request a new login token\r\n2. When you get the email, don't click on the \"Sign In\" link (this would invalidate the token prematurely).\r\n3. Copy the URL below the \"Trouble Signing In?\" header, and paste it into your browser.\r\n4. This should log you in.","bodyHTML":"

Some email providers will pre-visit the link when you click on it, which can invalidate the token.

\n

To remedy this:

\n
    \n
  1. Request a new login token
    2. \n
  2. When you get the email, don't click on the \"Sign In\" link (this would invalidate the token prematurely).
    3. \n
  3. Copy the URL below the \"Trouble Signing In?\" header, and paste it into your browser.
    4. \n
  4. This should log you in.
    5. \n
"}}} /> +

Trouble logging in to the Developer Portal with email

+\n

Tracked in ticket #108516

\n\n","bodyHTML":"

When I click the “Sign In” link it says the link is expired. I did it from the button and from copy/pasting the actual URL into the browser.

\n

What are next steps?

\n
\n\n

Tracked in ticket #108516

\n","answer":{"body":"Some email providers will pre-visit the link when you click on it, which can invalidate the token.\r\n\r\nTo remedy this:\r\n\r\n1. Request a new login token\r\n2. When you get the email, don't click on the \"Sign In\" link (this would invalidate the token prematurely).\r\n3. Copy the URL below the \"Trouble Signing In?\" header, and paste it into your browser.\r\n4. This should log you in.","bodyHTML":"

Some email providers will pre-visit the link when you click on it, which can invalidate the token.

\n

To remedy this:

\n
    \n
  1. Request a new login token
    2. \n
  2. When you get the email, don't click on the \"Sign In\" link (this would invalidate the token prematurely).
    3. \n
  3. Copy the URL below the \"Trouble Signing In?\" header, and paste it into your browser.
    4. \n
  4. This should log you in.
    5. \n
"}}} /> @@ -22,6 +22,6 @@ import GitHub from "/src/components/GitHub" diff --git a/docs/discussions/knowledge-base/535.mdx b/docs/discussions/knowledge-base/535.mdx index 6187284113..c8583072d6 100644 --- a/docs/discussions/knowledge-base/535.mdx +++ b/docs/discussions/knowledge-base/535.mdx @@ -14,7 +14,7 @@ import GitHub from "/src/components/GitHub" Knowledge Base

Expose cleanup_on_fail for k8s-service module

-\r\n

Tracked in ticket #109140

\r\n\r\n","bodyHTML":"

Hello, may we request to expose the cleanup_on_fail parameter of the helm_release resource on the k8s-service module?

\n

https://github.com/gruntwork-io/terraform-aws-service-catalog

\n
\n\n

Tracked in ticket #109140

\n","answer":{"body":"Hi, I opened a PR for this. \r\n\r\nPR: https://github.com/gruntwork-io/terraform-aws-service-catalog/pull/1669","bodyHTML":"

Hi, I opened a PR for this.

\n

PR: gruntwork-io/terraform-aws-service-catalog#1669

"}}} /> +\r\n

Tracked in ticket #109140

\r\n\r\n","bodyHTML":"

Hello, may we request to expose the cleanup_on_fail parameter of the helm_release resource on the k8s-service module?

\n

https://github.com/gruntwork-io/terraform-aws-service-catalog

\n
\n\n

Tracked in ticket #109140

\n","answer":{"body":"Hi, I opened a PR for this. \r\n\r\nPR: https://github.com/gruntwork-io/terraform-aws-service-catalog/pull/1669","bodyHTML":"

Hi, I opened a PR for this.

\n

PR: https://github.com/gruntwork-io/terraform-aws-service-catalog/pull/1669

"}}} /> @@ -22,6 +22,6 @@ import GitHub from "/src/components/GitHub" diff --git a/docs/discussions/knowledge-base/700.mdx b/docs/discussions/knowledge-base/700.mdx index d9eb070515..819fd276ef 100644 --- a/docs/discussions/knowledge-base/700.mdx +++ b/docs/discussions/knowledge-base/700.mdx @@ -14,7 +14,7 @@ import GitHub from "/src/components/GitHub" Knowledge Base

Mac OSX: "terraform" or "packer" will damage your computer. You should move it to the trash. Hashicorp tooling security errors.

- I\"ve just tried to run a Terraform command and got the following error on Mac OSX. What does this mean and how do I fix it? \r\n\r\n![terraform-damage](https://user-images.githubusercontent.com/1769996/234879120-900249fa-dc36-4a9f-b1a5-0732411019e6.png)\r\n\r\n\n\n---\n\n\n

Tracked in ticket #110126

\n\n","bodyHTML":"

A customer asked:

\n
\n

I\"ve just tried to run a Terraform command and got the following error on Mac OSX. What does this mean and how do I fix it?

\n
\n

\"terraform-damage\"

\n
\n\n

Tracked in ticket #110126

\n","answer":{"body":"## `tldr` What happened?\r\nHashiCorp intentionally invalidated several released binaries (Terraform, Packer, etc) in response to a CircleCI security incident. This means that the versions of the binaries that HashiCorp invalidated will not run properly on Mac OSX. This is expected to affect all HashiCorp projects (terraform, packer, nomad, etc).\r\n\r\n## `tldr` To fix this issue\r\nYou need to delete your current `terraform` or `packer` binary and re-install it again. Terraform, Packer and other HashiCorp binaries that were downloaded before January 23rd are now intended to not work properly. \r\n\r\n## To fix the issue when using `terraform` directly\r\n\r\nDelete your current `terraform` installation. [Re-install Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)\r\n\r\n## To fix the issue when using `tfenv`\r\n\r\nUsers report that it is possible to resolve the issue via `tfenv` by installing the latest version of Terraform. You may receive some errors on `STDOUT`: \r\n```\r\n$ tfenv install 1.2.6\r\nInstalling Terraform v1.2.6\r\nDownloading release tarball from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_darwin_amd64.zip\r\n######################################################################################################################################################################################################################################################### 100.0%\r\nDownloading SHA hash file from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_SHA256SUMS\r\n▶ ERROR No UID given but one was expected\r\nUnable to verify OpenPGP signature unless logged into keybase and following hashicorp\r\nArchive: /var/folders/qr/fqg8j0f50p96ss1yl436ls100000gn/T/tfenv_download.XXXXXX.jvmuCTni/terraform_1.2.6_darwin_amd64.zip\r\n inflating: /usr/local/Cellar/tfenv/3.0.0/versions/1.2.6/terraform\r\nInstallation of terraform v1.2.6 successful. To make this your default version, run 'tfenv use 1.2.6'\r\n```\r\n\r\n# Understanding why this issue is occuring\r\n\r\nOn January 3, 2023, CircleCI issued a security alert that they had discovered an unauthorized third party leveraged malware deployed to a CircleCI engineer’s laptop in order to steal a valid, 2FA-backed SSO session. Out of an abundance of caution, they began rotating all API token secrets for all customers. \r\n\r\nRecently, HashiCorp took their own action to rotate the signing key for their RPM packages. As a result, users must now re-download binaries that have been signed with the updated key.\r\nhttps://support.hashicorp.com/hc/en-us/articles/13177506317203","bodyHTML":"

tldr What happened?

\n

HashiCorp intentionally invalidated several released binaries (Terraform, Packer, etc) in response to a CircleCI security incident. This means that the versions of the binaries that HashiCorp invalidated will not run properly on Mac OSX. This is expected to affect all HashiCorp projects (terraform, packer, nomad, etc).

\n

tldr To fix this issue

\n

You need to delete your current terraform or packer binary and re-install it again. Terraform, Packer and other HashiCorp binaries that were downloaded before January 23rd are now intended to not work properly.

\n

To fix the issue when using terraform directly

\n

Delete your current terraform installation. Re-install Terraform

\n

To fix the issue when using tfenv

\n

Users report that it is possible to resolve the issue via tfenv by installing the latest version of Terraform. You may receive some errors on STDOUT:

\n
$ tfenv install 1.2.6\nInstalling Terraform v1.2.6\nDownloading release tarball from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_darwin_amd64.zip\n######################################################################################################################################################################################################################################################### 100.0%\nDownloading SHA hash file from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_SHA256SUMS\n▶ ERROR No UID given but one was expected\nUnable to verify OpenPGP signature unless logged into keybase and following hashicorp\nArchive:  /var/folders/qr/fqg8j0f50p96ss1yl436ls100000gn/T/tfenv_download.XXXXXX.jvmuCTni/terraform_1.2.6_darwin_amd64.zip\n  inflating: /usr/local/Cellar/tfenv/3.0.0/versions/1.2.6/terraform\nInstallation of terraform v1.2.6 successful. To make this your default version, run 'tfenv use 1.2.6'\n
\n

Understanding why this issue is occuring

\n

On January 3, 2023, CircleCI issued a security alert that they had discovered an unauthorized third party leveraged malware deployed to a CircleCI engineer’s laptop in order to steal a valid, 2FA-backed SSO session. Out of an abundance of caution, they began rotating all API token secrets for all customers.

\n

Recently, HashiCorp took their own action to rotate the signing key for their RPM packages. As a result, users must now re-download binaries that have been signed with the updated key.
\nhttps://support.hashicorp.com/hc/en-us/articles/13177506317203

"}}} /> + I\"ve just tried to run a Terraform command and got the following error on Mac OSX. What does this mean and how do I fix it? \r\n\r\n![terraform-damage](https://user-images.githubusercontent.com/1769996/234879120-900249fa-dc36-4a9f-b1a5-0732411019e6.png)\r\n\r\n\r\n\r\n---\r\n\r\n\r\n

Tracked in ticket #110126

\r\n\r\n","bodyHTML":"

A customer asked:

\n
\n

I\"ve just tried to run a Terraform command and got the following error on Mac OSX. What does this mean and how do I fix it?

\n
\n

\"terraform-damage\"

\n
\n\n

Tracked in ticket #110126

\n","answer":{"body":"## `tldr` What happened?\r\nHashiCorp intentionally invalidated several released binaries (Terraform, Packer, etc) in response to a CircleCI security incident. This means that the versions of the binaries that HashiCorp invalidated will not run properly on Mac OSX. This is expected to affect all HashiCorp projects (terraform, packer, nomad, etc).\r\n\r\n## `tldr` To fix this issue\r\nYou need to delete your current `terraform` or `packer` binary and re-install it again. Terraform, Packer and other HashiCorp binaries that were downloaded before January 23rd are now intended to not work properly. \r\n\r\n## To fix the issue when using `terraform` directly\r\n\r\nDelete your current `terraform` installation. [Re-install Terraform](https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli)\r\n\r\n## To fix the issue when using `tfenv`\r\n\r\nUsers report that it is possible to resolve the issue via `tfenv` by installing the latest version of Terraform. You may receive some errors on `STDOUT`: \r\n```\r\n$ tfenv install 1.2.6\r\nInstalling Terraform v1.2.6\r\nDownloading release tarball from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_darwin_amd64.zip\r\n######################################################################################################################################################################################################################################################### 100.0%\r\nDownloading SHA hash file from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_SHA256SUMS\r\n▶ ERROR No UID given but one was expected\r\nUnable to verify OpenPGP signature unless logged into keybase and following hashicorp\r\nArchive: /var/folders/qr/fqg8j0f50p96ss1yl436ls100000gn/T/tfenv_download.XXXXXX.jvmuCTni/terraform_1.2.6_darwin_amd64.zip\r\n inflating: /usr/local/Cellar/tfenv/3.0.0/versions/1.2.6/terraform\r\nInstallation of terraform v1.2.6 successful. To make this your default version, run 'tfenv use 1.2.6'\r\n```\r\n\r\n# Understanding why this issue is occuring\r\n\r\nOn January 3, 2023, CircleCI issued a security alert that they had discovered an unauthorized third party leveraged malware deployed to a CircleCI engineer’s laptop in order to steal a valid, 2FA-backed SSO session. Out of an abundance of caution, they began rotating all API token secrets for all customers. \r\n\r\nRecently, HashiCorp took their own action to rotate the signing key for their RPM packages. As a result, users must now re-download binaries that have been signed with the updated key.\r\nhttps://support.hashicorp.com/hc/en-us/articles/13177506317203","bodyHTML":"

tldr What happened?

\n

HashiCorp intentionally invalidated several released binaries (Terraform, Packer, etc) in response to a CircleCI security incident. This means that the versions of the binaries that HashiCorp invalidated will not run properly on Mac OSX. This is expected to affect all HashiCorp projects (terraform, packer, nomad, etc).

\n

tldr To fix this issue

\n

You need to delete your current terraform or packer binary and re-install it again. Terraform, Packer and other HashiCorp binaries that were downloaded before January 23rd are now intended to not work properly.

\n

To fix the issue when using terraform directly

\n

Delete your current terraform installation. Re-install Terraform

\n

To fix the issue when using tfenv

\n

Users report that it is possible to resolve the issue via tfenv by installing the latest version of Terraform. You may receive some errors on STDOUT:

\n
$ tfenv install 1.2.6\nInstalling Terraform v1.2.6\nDownloading release tarball from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_darwin_amd64.zip\n######################################################################################################################################################################################################################################################### 100.0%\nDownloading SHA hash file from https://releases.hashicorp.com/terraform/1.2.6/terraform_1.2.6_SHA256SUMS\n▶ ERROR No UID given but one was expected\nUnable to verify OpenPGP signature unless logged into keybase and following hashicorp\nArchive:  /var/folders/qr/fqg8j0f50p96ss1yl436ls100000gn/T/tfenv_download.XXXXXX.jvmuCTni/terraform_1.2.6_darwin_amd64.zip\n  inflating: /usr/local/Cellar/tfenv/3.0.0/versions/1.2.6/terraform\nInstallation of terraform v1.2.6 successful. To make this your default version, run 'tfenv use 1.2.6'\n
\n

Understanding why this issue is occuring

\n

On January 3, 2023, CircleCI issued a security alert that they had discovered an unauthorized third party leveraged malware deployed to a CircleCI engineer’s laptop in order to steal a valid, 2FA-backed SSO session. Out of an abundance of caution, they began rotating all API token secrets for all customers.

\n

Recently, HashiCorp took their own action to rotate the signing key for their RPM packages. As a result, users must now re-download binaries that have been signed with the updated key.
\nhttps://support.hashicorp.com/hc/en-us/articles/13177506317203

"}}} /> @@ -22,6 +22,6 @@ import GitHub from "/src/components/GitHub" diff --git a/docs/discussions/knowledge-base/713.mdx b/docs/discussions/knowledge-base/713.mdx new file mode 100644 index 0000000000..18eb668a8c --- /dev/null +++ b/docs/discussions/knowledge-base/713.mdx @@ -0,0 +1,27 @@ +--- +hide_table_of_contents: true +hide_title: true +custom_edit_url: null +--- + +import CenterLayout from "/src/components/CenterLayout" +import GitHub from "/src/components/GitHub" + + + + + + +Knowledge Base +

How can I change my GitHub account(unlink/link)?

+\n

Tracked in ticket #110184

\n\n","bodyHTML":"

Frequently asked question: How can I change the GitHub account linked in my Developer Portal account?

\n
\n\n

Tracked in ticket #110184

\n","answer":{"body":"\"unlink-github\"\r\n\r\n1. Go to [https://app.gruntwork.io/settings/profile](https://app.gruntwork.io/settings/profile).\r\n1. Click the **Unlink** link in the “GitHub Account” section as shown in image above.\r\n1. [Follow these steps](https://docs.gruntwork.io/intro/dev-portal/link-github-id) to link a new GitHub account *using a private/incognito browser window*.\r\n \r\n >💡\r\n >\r\n >A private/incognito browser window guarantees you’ll have the opportunity to specify the new Github account you wish to link.","bodyHTML":"\"unlink-github\"\n
    \n
  1. \n

    Go to https://app.gruntwork.io/settings/profile.

    \n
    2. \n
  2. \n

    Click the Unlink link in the “GitHub Account” section as shown in image above.

    \n
    3. \n
  3. \n

    Follow these steps to link a new GitHub account using a private/incognito browser window.

    \n
    \n

    💡

    \n

    A private/incognito browser window guarantees you’ll have the opportunity to specify the new Github account you wish to link.

    \n
    \n
    4. \n
"}}} /> + + + + + diff --git a/docs/discussions/knowledge-base/714.mdx b/docs/discussions/knowledge-base/714.mdx new file mode 100644 index 0000000000..55babf9916 --- /dev/null +++ b/docs/discussions/knowledge-base/714.mdx @@ -0,0 +1,27 @@ +--- +hide_table_of_contents: true +hide_title: true +custom_edit_url: null +--- + +import CenterLayout from "/src/components/CenterLayout" +import GitHub from "/src/components/GitHub" + + + + + + +Knowledge Base +

How can I change the email associated with my account?

+\n

Tracked in ticket #110185

\n\n","bodyHTML":"

Frequently asked question: How can I change the email associated with my account in the Gruntwork Developer Portal?

\n
\n\n

Tracked in ticket #110185

\n","answer":{"body":"**Emails cannot be changed.**\r\n\r\nEmails serve as the primary authentication & identification mechanisms — essentially functioning as a username. For both of these reasons, changing them is currently unsupported.\r\n\r\nIf a you need to use a different email (for instance, if you were using a personal email before, or your company domain changed), then:\r\n\r\n1. You or an admin on your team will need to send invitations to the new email(s).\r\n1. Accept the invitation for the new email to create a new user and sign in.\r\n1. Link your GitHub account to the new user profile when prompted after sign in.\r\n >⚠️\r\n >\r\n >In order to ensure you do not lose any access, link the same GitHub account(that is linked to the older user account) before the old user account is revoked.\r\n1. Remove the old user account from your Organization in the Developer Portal to prevent duplicate license usage","bodyHTML":"

Emails cannot be changed.

\n

Emails serve as the primary authentication & identification mechanisms — essentially functioning as a username. For both of these reasons, changing them is currently unsupported.

\n

If a you need to use a different email (for instance, if you were using a personal email before, or your company domain changed), then:

\n
    \n
  1. You or an admin on your team will need to send invitations to the new email(s).
    2. \n
  2. Accept the invitation for the new email to create a new user and sign in.
    3. \n
  3. Link your GitHub account to the new user profile when prompted after sign in.\n
    \n

    ⚠️

    \n

    In order to ensure you do not lose any access, link the same GitHub account(that is linked to the older user account) before the old user account is revoked.

    \n
    \n
    4. \n
  4. Remove the old user account from your Organization in the Developer Portal to prevent duplicate license usage
    5. \n
"}}} /> + + + + + diff --git a/docs/discussions/knowledge-base/715.mdx b/docs/discussions/knowledge-base/715.mdx new file mode 100644 index 0000000000..a2675adc5b --- /dev/null +++ b/docs/discussions/knowledge-base/715.mdx @@ -0,0 +1,27 @@ +--- +hide_table_of_contents: true +hide_title: true +custom_edit_url: null +--- + +import CenterLayout from "/src/components/CenterLayout" +import GitHub from "/src/components/GitHub" + + + + + + +Knowledge Base +

I have linked my GitHub Account but do not have code access

+\n

Tracked in ticket #110186

\n\n","bodyHTML":"

Frequently asked question: I have linked my GitHub Account in the Gruntwork Developer Portal but I still do not have code access.

\n
\n\n

Tracked in ticket #110186

\n","answer":{"body":"If you have linked a GitHub account in the Developer Portal but do not have access to our private repositories it is likely due to not accepting the GitHub invitation that was sent to you. Check the email associated with your GitHub account for the invitation.\r\n\r\n>💡\r\n>The GitHub invitation typically expires after 7 days.\r\n>\r\n>To get a new invitation, sign in to the Developer Portal and you will be automatically re-invited. After sign in, check the inbox of the email associated with your GitHub account for the new invitation.\r\n\r\nIf you are still unable to find the GitHub invitation contact your Organization's GitHub Administrator to verify if your Organization uses GitHub Enterprise. In cases like these, there are policies / settings that your GitHub Enterprise administrator may have configured, which block your ability to view and accept our invitations. When this happens, Gruntwork is unable to assist you further until your GitHub Enterprise administrator has relaxed the constraints on your account.","bodyHTML":"

If you have linked a GitHub account in the Developer Portal but do not have access to our private repositories it is likely due to not accepting the GitHub invitation that was sent to you. Check the email associated with your GitHub account for the invitation.

\n
\n

💡
\nThe GitHub invitation typically expires after 7 days.

\n

To get a new invitation, sign in to the Developer Portal and you will be automatically re-invited. After sign in, check the inbox of the email associated with your GitHub account for the new invitation.

\n
\n

If you are still unable to find the GitHub invitation contact your Organization's GitHub Administrator to verify if your Organization uses GitHub Enterprise. In cases like these, there are policies / settings that your GitHub Enterprise administrator may have configured, which block your ability to view and accept our invitations. When this happens, Gruntwork is unable to assist you further until your GitHub Enterprise administrator has relaxed the constraints on your account.

"}}} /> + + + + + diff --git a/docs/discussions/knowledge-base/716.mdx b/docs/discussions/knowledge-base/716.mdx new file mode 100644 index 0000000000..3f0a0f4728 --- /dev/null +++ b/docs/discussions/knowledge-base/716.mdx @@ -0,0 +1,27 @@ +--- +hide_table_of_contents: true +hide_title: true +custom_edit_url: null +--- + +import CenterLayout from "/src/components/CenterLayout" +import GitHub from "/src/components/GitHub" + + + + + + +Knowledge Base +

I did not receive an invitation to the Developer Portal

+\n

Tracked in ticket #110187

\n\n","bodyHTML":"

Frequently asked question: I have been invited by an Admin but I did not receive the email invitation into the Gruntwork Developer Portal.

\n
\n\n

Tracked in ticket #110187

\n","answer":{"body":"Follow these steps:\r\n\r\n1. Check your spam folder for emails from `grunty@gruntwork.io`.\r\n1. If you don't find the email, try signing into the [Developer Portal](https://app.gruntwork.io) using the email address you were invited with. The Portal will automatically resend the email invitation.\r\n1. If you still did not receive your email invitation, contact .","bodyHTML":"

Follow these steps:

\n
    \n
  1. Check your spam folder for emails from grunty@gruntwork.io.
    2. \n
  2. If you don't find the email, try signing into the Developer Portal using the email address you were invited with. The Portal will automatically resend the email invitation.
    3. \n
  3. If you still did not receive your email invitation, contact support@gruntwork.io.
    4. \n
"}}} /> + + + + + diff --git a/docs/discussions/knowledge-base/717.mdx b/docs/discussions/knowledge-base/717.mdx new file mode 100644 index 0000000000..098ff2b556 --- /dev/null +++ b/docs/discussions/knowledge-base/717.mdx @@ -0,0 +1,27 @@ +--- +hide_table_of_contents: true +hide_title: true +custom_edit_url: null +--- + +import CenterLayout from "/src/components/CenterLayout" +import GitHub from "/src/components/GitHub" + + + + + + +Knowledge Base +

CIS Reference Architecture - GuardDuty being recreated with v0.38.0

+\n

Tracked in ticket #110188

\n\n","bodyHTML":"

I bumped my CIS Service Catalog version to v0.38.0 and have been presented with many recreations. The release notes have an example, but how does this look with the Reference Architecture?

\n
// ...\n  # module.security_baseline.module.guardduty[0].module.guardduty_sa_east_1.aws_guardduty_detector.guardduty[0] will be created\n  + resource \"aws_guardduty_detector\" \"guardduty\" {\n      + account_id                   = (known after apply)\n      + arn                          = (known after apply)\n      + enable                       = true\n      + finding_publishing_frequency = (known after apply)\n      + id                           = (known after apply)\n      + tags_all                     = (known after apply)\n\n      + datasources {\n          + s3_logs {\n              + enable = (known after apply)\n            }\n        }\n    }\n\n  # module.security_baseline.module.guardduty[0].module.guardduty_us_east_1.aws_guardduty_detector.guardduty[0] will be created\n  + resource \"aws_guardduty_detector\" \"guardduty\" {\n      + account_id                   = (known after apply)\n      + arn                          = (known after apply)\n      + enable                       = true\n      + finding_publishing_frequency = (known after apply)\n      + id                           = (known after apply)\n      + tags_all                     = (known after apply)\n\n      + datasources {\n          + s3_logs {\n              + enable = (known after apply)\n            }\n        }\n    }\n\n  # module.security_baseline.module.guardduty[0].module.guardduty_us_east_2.aws_guardduty_detector.guardduty[0] will be created\n  + resource \"aws_guardduty_detector\" \"guardduty\" {\n      + account_id                   = (known after apply)\n      + arn                          = (known after apply)\n      + enable                       = true\n      + finding_publishing_frequency = (known after apply)\n      + id                           = (known after apply)\n      + tags_all                     = (known after apply)\n\n      + datasources {\n          + s3_logs {\n              + enable = (known after apply)\n            }\n        }\n    }\n\n  # module.security_baseline.module.guardduty[0].module.guardduty_us_west_1.aws_guardduty_detector.guardduty[0] will be created\n  + resource \"aws_guardduty_detector\" \"guardduty\" {\n      + account_id                   = (known after apply)\n      + arn                          = (known after apply)\n      + enable                       = true\n      + finding_publishing_frequency = (known after apply)\n      + id                           = (known after apply)\n      + tags_all                     = (known after apply)\n\n      + datasources {\n          + s3_logs {\n              + enable = (known after apply)\n            }\n        }\n    }\n\n  # module.security_baseline.module.guardduty[0].module.guardduty_us_west_2.aws_guardduty_detector.guardduty[0] will be created\n  + resource \"aws_guardduty_detector\" \"guardduty\" {\n      + account_id                   = (known after apply)\n      + arn                          = (known after apply)\n      + enable                       = true\n      + finding_publishing_frequency = (known after apply)\n      + id                           = (known after apply)\n      + tags_all                     = (known after apply)\n\n      + datasources {\n          + s3_logs {\n              + enable = (known after apply)\n            }\n        }\n    }\n  // ...
\n
\n\n

Tracked in ticket #110188

\n","answer":{"body":"### Background\r\nIf we check the release notes, https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/releases/tag/v0.38.0, we see we need to do some `terraform state mv` work:\r\n\r\n>The Guardduty module call has been adjusted to be a count based module. This requires state migrations to avoid a recreation of the Guardduty resources.\r\n...\r\n**account-baseline-security**\r\n>```hcl\r\n>terragrunt state mv module.security_baseline.module.guardduty 'module.security_baseline.module.guardduty[0]'\r\n>```\r\n\r\n## How to apply this to the Reference Architecture \r\n### Generate a list of current resources represented in the remote state\r\nI took a list of all the resources to find out what the GuardDuty addresses looked like in the `terraform state` file:\r\n\r\n```sh\r\ninfrastructure-live-ian/security/_global/account-baseline $ aws-vault exec gruntwork-sales-security-02-admin -- terragrunt state list > 1.tmp\r\n```\r\n\r\nI see all my GuardDuty resources look something like this:\r\n```hcl\r\n// ...\r\nmodule.security_baseline.module.guardduty.module.guardduty_eu_west_2.aws_guardduty_detector.guardduty[0]\r\nmodule.security_baseline.module.guardduty.module.guardduty_eu_west_3.aws_guardduty_detector.guardduty[0]\r\nmodule.security_baseline.module.guardduty.module.guardduty_sa_east_1.aws_guardduty_detector.guardduty[0]\r\nmodule.security_baseline.module.guardduty.module.guardduty_us_east_1.aws_guardduty_detector.guardduty[0]\r\nmodule.security_baseline.module.guardduty.module.guardduty_us_east_2.aws_guardduty_detector.guardduty[0]\r\nmodule.security_baseline.module.guardduty.module.guardduty_us_west_1.aws_guardduty_detector.guardduty[0]\r\nmodule.security_baseline.module.guardduty.module.guardduty_us_west_2.aws_guardduty_detector.guardduty[0]\r\n// ...\r\n```\r\n\r\n### Note what needs to change\r\nThe release notes imply this:\r\n```hcl\r\nmodule.security_baseline.module.guardduty.module.guardduty_eu_west_2.aws_guardduty_detector.guardduty[0]\r\n```\r\n\r\nShould look like this (a `[0]` after the first mention of `guardduty`):\r\n```\r\nmodule.security_baseline.module.guardduty[0].module.guardduty_eu_west_2.aws_guardduty_detector.guardduty[0]\r\n````\r\n\r\n### Note the total number of resources to be recreated \r\nIn my case, it was `29` when I first ran my `terragrunt plan` after changing my CIS Service Catalog version to `v0.38.0`. \r\n\r\n### Resolving the issue\r\nThis is easy to write a small script for, but I picked the first region in the list I generated and did the `terragrunt state mv` manually to confirm it behaves as expected, and checked to see that my `terragrunt plan` once I've finished the `mv` shows only `28 to add`. The reason I want it to be `28` and not `29` is because that verifies I have successfully fixed the issue with GuardDuty detectors being needlessly recreated in every region I have listed in my `opt_in_regions` list, located here: https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/examples/for-production/infrastructure-live/multi_region_common.hcl#L43. \r\n\r\nHere is the actual command I ran to do the `state mv` manually (note the quotes and needing to authenticate to AWS still):\r\n\r\n```\r\n(base) ~/tmp/infrastructure-live-ian/security/_global/account-baseline 127 $ aws-vault exec gruntwork-sales-security-02-admin -- terragrunt state mv 'module.security_baseline.module.guardduty.module.guardduty_ap_northeast_1.aws_guardduty_detector.guardduty[0]' 'module.security_baseline.module.guardduty[0].module.guardduty_ap_northeast_1.aws_guardduty_detector.guardduty[0]'\r\n```\r\n\r\nOnce that is done, run a `terragrunt plan` and confirm the number of new resources to be created has decreased by one, and then double check the plan to ensure that the region you selected, `guardduty_ap_northeast_1`, in my case, does not show up. \r\n\r\n### Additional \r\nIf you're particularly paranoid, you could do a `terraform state pull` (which still requires authenticating to AWS) and point to a local copy first to test `plan` against, but that is probably overkill and would require more potentially dodgy hand-work. \r\n\r\n","bodyHTML":"

Background

\n

If we check the release notes, https://github.com/gruntwork-io/terraform-aws-cis-service-catalog/releases/tag/v0.38.0, we see we need to do some terraform state mv work:

\n
\n

The Guardduty module call has been adjusted to be a count based module. This requires state migrations to avoid a recreation of the Guardduty resources.
\n...
\naccount-baseline-security

\n
terragrunt state mv module.security_baseline.module.guardduty 'module.security_baseline.module.guardduty[0]'
\n
\n

How to apply this to the Reference Architecture

\n

Generate a list of current resources represented in the remote state

\n

I took a list of all the resources to find out what the GuardDuty addresses looked like in the terraform state file:

\n
infrastructure-live-ian/security/_global/account-baseline $ aws-vault exec gruntwork-sales-security-02-admin -- terragrunt state list > 1.tmp
\n

I see all my GuardDuty resources look something like this:

\n
// ...\nmodule.security_baseline.module.guardduty.module.guardduty_eu_west_2.aws_guardduty_detector.guardduty[0]\nmodule.security_baseline.module.guardduty.module.guardduty_eu_west_3.aws_guardduty_detector.guardduty[0]\nmodule.security_baseline.module.guardduty.module.guardduty_sa_east_1.aws_guardduty_detector.guardduty[0]\nmodule.security_baseline.module.guardduty.module.guardduty_us_east_1.aws_guardduty_detector.guardduty[0]\nmodule.security_baseline.module.guardduty.module.guardduty_us_east_2.aws_guardduty_detector.guardduty[0]\nmodule.security_baseline.module.guardduty.module.guardduty_us_west_1.aws_guardduty_detector.guardduty[0]\nmodule.security_baseline.module.guardduty.module.guardduty_us_west_2.aws_guardduty_detector.guardduty[0]\n// ...
\n

Note what needs to change

\n

The release notes imply this:

\n
module.security_baseline.module.guardduty.module.guardduty_eu_west_2.aws_guardduty_detector.guardduty[0]
\n

Should look like this (a [0] after the first mention of guardduty):

\n
module.security_baseline.module.guardduty[0].module.guardduty_eu_west_2.aws_guardduty_detector.guardduty[0]\n
\n

Note the total number of resources to be recreated

\n

In my case, it was 29 when I first ran my terragrunt plan after changing my CIS Service Catalog version to v0.38.0.

\n

Resolving the issue

\n

This is easy to write a small script for, but I picked the first region in the list I generated and did the terragrunt state mv manually to confirm it behaves as expected, and checked to see that my terragrunt plan once I've finished the mv shows only 28 to add. The reason I want it to be 28 and not 29 is because that verifies I have successfully fixed the issue with GuardDuty detectors being needlessly recreated in every region I have listed in my opt_in_regions list, located here: https://github.com/gruntwork-io/terraform-aws-service-catalog/blob/master/examples/for-production/infrastructure-live/multi_region_common.hcl#L43.

\n

Here is the actual command I ran to do the state mv manually (note the quotes and needing to authenticate to AWS still):

\n
(base) ~/tmp/infrastructure-live-ian/security/_global/account-baseline 127 $ aws-vault exec gruntwork-sales-security-02-admin -- terragrunt state mv 'module.security_baseline.module.guardduty.module.guardduty_ap_northeast_1.aws_guardduty_detector.guardduty[0]' 'module.security_baseline.module.guardduty[0].module.guardduty_ap_northeast_1.aws_guardduty_detector.guardduty[0]'\n
\n

Once that is done, run a terragrunt plan and confirm the number of new resources to be created has decreased by one, and then double check the plan to ensure that the region you selected, guardduty_ap_northeast_1, in my case, does not show up.

\n

Additional

\n

If you're particularly paranoid, you could do a terraform state pull (which still requires authenticating to AWS) and point to a local copy first to test plan against, but that is probably overkill and would require more potentially dodgy hand-work.

"}}} /> + + + + + diff --git a/docs/discussions/knowledge-base/718.mdx b/docs/discussions/knowledge-base/718.mdx new file mode 100644 index 0000000000..e2e6d4b2be --- /dev/null +++ b/docs/discussions/knowledge-base/718.mdx @@ -0,0 +1,27 @@ +--- +hide_table_of_contents: true +hide_title: true +custom_edit_url: null +--- + +import CenterLayout from "/src/components/CenterLayout" +import GitHub from "/src/components/GitHub" + + + + + + +Knowledge Base +

Where are the IAM permissions located for the ecs-deploy-runner in the Reference Architecture?

+\n

Tracked in ticket #110196

\n\n","bodyHTML":"

Where are the IAM permissions located for the ecs-deploy-runner in the Reference Architecture? I need to build a new Packer image in the shared account and add permissions to deploy an EKS cluster, as my initial setup was with ECS.

\n
\n\n

Tracked in ticket #110196

\n","answer":{"body":"The IAM policies that are attached to the deployer role should be located as YAML files at `_envcommon/mgmt/`.","bodyHTML":"

The IAM policies that are attached to the deployer role should be located as YAML files at _envcommon/mgmt/.

"}}} /> + + + + +