search

aws-samples / lza-validator

Build a tool that can validate configurations of Landing Zone Accelerator on AWS.
MIT No Attribution
10 stars 7 forks source link

AWS creds *do* seem to be required to run the validator #6

Closed eddydee123 closed 5 months ago

eddydee123 commented 5 months ago 
          Generally speaking, you should not need credentials to validate the configs

Originally posted by @jc1518 in https://github.com/aws-samples/lza-validator/issues/5#issuecomment-2002912081

If you have an AWS Organization set up, it seems that the validator tries to access it and gets stuck if it can't. I can't share my configurations files here, but this is the behavior I observed:

Following the instructions in the README, the container launched and started executing and then made no further progress:

$ docker run --rm --volume ~/aws-accelerator-config:/lza/config lza-validator:v1.6.3
yarn run v1.22.19
$ ts-node ./packages/@aws-accelerator/accelerator/lib/config-validator.ts /lza/config/
2024-05-21 17:33:54.879 | info | config-validator | Found replacement variables in customizations-config.yaml
2024-05-21 17:33:54.880 | info | config-validator | Config source directory -  /lza/config/
<get stuck here>

Passing -e NODE_DEBUG=* to the docker run showed that the validator is executing but seems to be timing out on some HTTP request. No further useful information was available.

Randy mentioned on a call that the validator needs to access my live AWS environment. Adding the relevant environment variables solved the problem right away:

$ docker run --rm --env-file <(aws configure export-credentials --format env-no-export) --volume ~/aws-accelerator-config:/lza/config lza-validator:v1.6.3
yarn run v1.22.19
$ ts-node [./packages/@aws-accelerator/accelerator/lib/config-validator.ts](mailto:./packages/@aws-accelerator/accelerator/lib/config-validator.ts) /lza/config/
2024-05-21 16:20:19.511 | info | config-validator | Found replacement variables in customizations-config.yaml
2024-05-21 16:20:19.512 | info | config-validator | Config source directory -  /lza/config/
2024-05-21 16:20:20.633 | info | replacements-config | Loading replacements config substitution values
2024-05-21 16:20:20.673 | info | accounts-config-validator | accounts-config.yaml file validation started
2024-05-21 16:20:20.674 | info | customizations-config-validator | customizations-config.yaml file validation started
2024-05-21 16:20:20.677 | info | global-config-validator | global-config.yaml file validation started
2024-05-21 16:20:20.680 | info | global-config-validator | email count: 1
2024-05-21 16:20:20.681 | info | iam-config-validator | iam-config.yaml file validation started
2024-05-21 16:20:20.683 | info | network-config-validator | network-config.yaml file validation started
2024-05-21 16:20:20.687 | info | organization-config-validator | organization-config.yaml file validation started
2024-05-21 16:20:20.688 | info | security-config-validator | security-config.yaml file validation started
2024-05-21 16:20:20.692 | info | replacement-config-validator | replacements-config.yaml file validation started
2024-05-21 16:20:20.693 | info | config-validator | Config file validation successful.
Done in 17.55s.

I suggest adding this to the README, and perhaps adding some error output indicating the problem.

jc1518 commented 5 months ago

Hi @eddydee123 , based on the log you provided I guess that you use Parameter Store reference variables in the replacements-config.yaml? If that's the case, I think credential is needed for the ssm parameter retrieval.

jc1518 commented 5 months ago

Instruction has been updated to reflect this use case. Thanks for bringing it to my attention.

eddydee123 commented 5 months ago

Thanks @jc1518 - actually we aren't using substitutions from the Parameter Store but there are other lookups which are probably causing the issue.

Another problem (let me know if I should open a separate issue for this): everything runs fine when I'm directly connected to the internet, but behind my corporate proxy it doesn't work. I get the same behavior as described in my first post before I passed in the AWS creds: it gets stuck in the same place.

I've passed in the HTTP(S)_PROXY and http(s)_proxy environment variables in the docker run command, and I've verified that the running container has internet connectivity, e.g. curl works fine.

Does the solution support running behind a proxy?

jc1518 commented 5 months ago

LZA-Validator uses the config-validator.ts from the LZA repository to validate config files. So whether supporting proxy or not are dependent on that.

Since AWS javascript SDK does not use proxy environment, it has to be specified in the code, e.g proxy-agent. And I could find a proxy parameter that can be passed to config-validator. So you need to raise an issue in the LZA repository if you would like to have the proxy feature in the validator.