# Testing AWS IAM policies
## Introduction
AWS IAM policies are notouriously complex, it is too easy to add some unintended permissions and it is surprisingly difficult to identify these in heavily used AWS accounts.
Thankfully AWS has provided an [IAM simulator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html) that allows you to evaluate existing or new policies for its behavior. Which is very nice, but doing this manually is quite time consuming and it is unrealistic to test the entire environment for what you are trying to do.
However, in good AWS spirit the simulator has an API and this tool provides automation on top of it. It allows you to define the complete list of actions you want to evaluate against what resources, which allows you to run these tests on a regular basis or (better) integrate it in your CI/CD pipeline.
## Testing approach
The testing leverages AWS' [IAM simulator (api)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html), that basically includes the same IAM evaluation logic that is applied when working in the console or using the cli. The beneits of this approach are:
- It takes all different levels of policies into account. Think about permission boundaries, service control policies and so on.
- It is an official service from AWS, so you can expect this to kept up to date over time.
- The actual actions are evaluated, but NOT executed. Hence no need for cleaning up resources after testing.
# Quick testing
For convenience, you can use this tool to quickly test whether a user has a specific permission on a particular resource:
```bash
$ aws-iam-tester access -u the_user -a 'glue:DeleteTable'
Test:
Source: arn:aws:iam::208912673223:user/the_user
Action: glue:DeleteTable
Resource: *
Result: allowed
Matched statements:
Policy: admin_permissions
Type: IAM Policy
Start: L3:C17
End: L8:C6
```
Or to see who has access to a particular resource and action by omitting both `user` and `role`:
```bash
$ aws-iam-tester access -a "s3:PutObject"
..............
Summary:
| Source | Action | Resource | Decision | Policies |
|----------------------------------------------------------|--------------|------------|------------|---------------------|
| arn:aws:iam::XXXXXXXXXXXX:user/the_user | s3:PutObject | * | allowed | admins_permissions |
| arn:aws:iam::xxxxxxxxxxxx:role/the_role | s3:PutObject | * | allowed | AdministratorAccess |
```
## Finding out who has access to a particular action/resource combination
It might be useful to check your highly senstive resources and find out who exactly can access these.
```bash
$ aws-iam-tester access -a "s3:PutObject" -R "arn:aws:s3:::my-strictly-confidential-data"
..............
Summary:
| Source | Action | Resource | Decision | Policies |
|----------------------------------------------------------|--------------|--------------------------------------------|------------|---------------------|
| arn:aws:iam::XXXXXXXXXXXX:user/the_user | s3:PutObject | arn:aws:s3:::my-strictly-confidential-data | allowed | admins_permissions |
| arn:aws:iam::xxxxxxxxxxxx:role/the_role | s3:PutObject | arn:aws:s3:::my-strictly-confidential-data | allowed | AdministratorAccess |
```
# Account testing
However, the initial purpose of this tool is to check an entire account whether there are no users and/or roles having permissons which they should not have.
## Configuration
In order to run, a configuration of the tests to run is required.
A sample configuration (with only one test) is shown, in various steps.
First there is a global section where you define settings which are applied to all tests (unless overruled, more on that later).
```yaml
---
user_landing_account: 0123456789 # ID of AWS Account that is allowed to assume roles in the test account
global_exemptions: # The roles and/or users below will be ignored in all tests. Regular expressions are supported
- "^arn:aws:iam::(\\d{12}):user/(.*)(ADMIN|admin)(.*)$"
- "^arn:aws:iam::(\\d{12}):role/(.*)(ADMIN|admin)(.*)$"
- "^arn:aws:iam::(\\d{12}):role/AWSCloudFormationStackSetExecutionRole$"
```
Then you define a list of tests, each consisting at least of a set of:
- actions
- resources
- the expected result (should it fail or succeed)
```yaml
# List of tests to execute. In general the configurations follow the rules of the AWS IAM Policy Simulator.
# For more information: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html
tests:
- actions: # list of actions to validate
- "*:*"
- iam:*
- iam:AddUser*
- iam:Attach*
- iam:Create*
- iam:Delete*
- iam:Detach*
- iam:Pass*
- iam:Put*
- iam:Remove*
- iam:UpdateAccountPasswordPolicy
- sts:AssumeRole
- sts:AssumeRoleWithSAML
expected_result: fail # 'fail' or 'succeed'
resources: # list of resources to validate against
- "*"
```
Rather than using all users and roles (without exemptions) you can also limit your test to a particular set of users and roles.
The test below does that, including defining a custom context that specifies multi factor authentication is disabled when running the test. By default the context under which the simulations are run assumes MFA is enabled, but you can override that with the `custom_context` element. For more information see the [AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html).
```yaml
- actions: # Same list of actions, but now check (with a custom context) whether
- "*:*"
- iam:*
- iam:AddUser*
- iam:Attach*
- iam:Create*
- iam:Delete*
- iam:Detach*
- iam:Pass*
- iam:Put*
- iam:Remove*
- iam:UpdateAccountPasswordPolicy
- sts:AssumeRole
- sts:AssumeRoleWithSAML
expected_result: fail # 'fail' or 'succeed'
resources: # list of resources to validate against
- "*"
limit_to: # check this list for the admin users
- "^arn:aws:iam::(\\d*):user/(.*)(ADMIN|admin)(.*)$"
- "^arn:aws:iam::(\\d*):role/(.*)(ADMIN|admin)(.*)$"
# test if the admins are required to use multi factor authentication
custom_context:
- context_key_name: aws:MultiFactorAuthPresent
context_key_values: false
context_key_type: boolean
```
Or if you want to do that for **all** tests you can use the `global_limit_to`:
```yaml
---
user_landing_account: 0123456789 # ID of AWS Account that is allowed to assume roles in the test account
global_limit_to: # These roles and/or users below will be u. Regular expressions are supported
- "^arn:aws:iam::(\\d{12}):user/(.*)(ENGINEER|engineer)(.*)$"
- "^arn:aws:iam::(\\d{12}):role/(.*)(SCIENTIST|scientist)(.*)$"
```
Below an example where an additional set of roles is exempt from testing:
```yaml
- actions: # list of data centric actions
- redshift:GetClusterCredentials
- redshift:JoinGroup
- rds:Create*
- rds:Delete*
- rds:Modify*
- rds-db:connect
- s3:BypassGovernanceRetention
- s3:CreateBucket
- s3:DeleteBucket
- s3:DeleteBucketPolicy
- s3:PutBucketAcl
- s3:PutBucketPolicy
- s3:PutEncryptionConfiguration
- s3:ReplicateDelete
expected_result: fail # 'fail' or 'succeed'
resources: # list of resources to validate against
- "*"
exemptions: [
- "^arn:aws:iam::(\\d{12}):role/(.*)_worker$" # ignore this for the worker roles
]
```
If you want to run positive tests (i.e. tests that you need to succeed rather than fail), these `exemptions` don't work that well.
In that case you can limit your tests to a set of roles and users:
```yaml
- actions:
- s3:PutObject
expected_result: succeed
resources:
- "arn:aws:s3:::my_bucket/xyz/*"
limit_to: # if you specify this, test will only be performed for the sources below
- "^arn:aws:iam::(\\d{12}):role/my_worker$"
```
> Note that the exemptions are ignored when using a `limit_to` list.
### Using a dynamic account id in the resource arn
In case you **need** to specify the `account id` in the resource arn, you can specificy this as follows:
```yaml
- actions:
- "secretsmanager:GetSecretValue"
expected_result: succeed
resources:
- "arn:aws:secretsmanager:eu-central-1:{account_id}:secret:my-secret/*"
```
### Using regular expressions for user and role matching
Regular expressions can be used when checking the users and/or roles that need to be included in the tests. Hence they are supported for the following elements in the config file:
- limit_to (the filtered list of users/roles to be used for a particular test)
- global_limit_to (the filtered list of users/roles to be used for all tests)
- exemptions (the filtered list of users/roles that should be excluded from a particular test)
- global_exemptions (the filtered list of users/roles that should be excluded from all tests)
> For all other elements, regular expression matching is NOT supported!
## How to use
Assuming you have define a config.yml in your local directory, then to run and write the outputs to the local `./results` directory:
```bash
aws-iam-tester --write-to-file
```
Using a specific config file:
```bash
aws-iam-tester --config-file my-config.yml
```
Using a specific output location:
```bash
aws-iam-tester --output-location /tmp
```
Or write to s3:
```bash
aws-iam-tester --output-location s3://my-bucket/my-prefix
```
Include only roles that can be assumed by human beings:
```bash
aws-iam-tester --no-include-system-roles
```
> Note: including system roles does NOT include the aws service roles.
Or print debug output:
```bash
aws-iam-tester --debug
```
To run a limited number of evaluations (which helps speeding things up, and avoiding API throttling issues):
```bash
aws-iam-tester --number-of-runs 10
```
For more information, run `aws-iam-tester --help` for more instructions.
## Return codes
The tester returns the following return codes:
- 0 upon successful completion with NO findings
- 1 upon successful completion with findings
- 2 (or higher) on failures
## Required permissions
Obviously the client has to run under an AWS security context that has sufficient permissions to query the IAM resources and run the simulator.
The following permissions are needed at the minimum:
```yaml
- sts:GetCallerIdentity
- iam:ListAccountAliases
- iam:ListRoles
- iam:ListUsers
- iam:SimulatePrincipalPolicy
```
And if you want to write the output to an s3 location, then obviously you need write access (`s3:PutObject`) to that particular location as well.
## Unit testing
`pytest` is being used for testing the various options.
As long as the `aws-iam-tester` module is installed, you can run the [tests](./tests).
```console
pytest -vsx
# or, alternatively
poetry run pytest -vsx
```
After installing `tox`, you can also simply run `$ tox`.
Raw data
{
"_id": null,
"home_page": "https://github.com/gercograndia/aws-iam-tester",
"name": "aws-iam-tester",
"maintainer": null,
"docs_url": null,
"requires_python": "<4.0.0,>=3.7.2",
"maintainer_email": null,
"keywords": "AWS, IAM, Policy, Tester, Evaluation, Simulator",
"author": "Gerco Grandia",
"author_email": "gerco.grandia@4synergy.nl",
"download_url": "https://files.pythonhosted.org/packages/ce/3f/cb4630f49e8fab2d4ccfc644e6914a6d06b75ba6c4fd352e550935b57f67/aws_iam_tester-1.0.6.tar.gz",
"platform": null,
"description": "# Testing AWS IAM policies\n\n## Introduction\n\nAWS IAM policies are notouriously complex, it is too easy to add some unintended permissions and it is surprisingly difficult to identify these in heavily used AWS accounts.\n\nThankfully AWS has provided an [IAM simulator](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html) that allows you to evaluate existing or new policies for its behavior. Which is very nice, but doing this manually is quite time consuming and it is unrealistic to test the entire environment for what you are trying to do.\n\nHowever, in good AWS spirit the simulator has an API and this tool provides automation on top of it. It allows you to define the complete list of actions you want to evaluate against what resources, which allows you to run these tests on a regular basis or (better) integrate it in your CI/CD pipeline.\n\n## Testing approach\n\nThe testing leverages AWS' [IAM simulator (api)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html), that basically includes the same IAM evaluation logic that is applied when working in the console or using the cli. The beneits of this approach are:\n\n- It takes all different levels of policies into account. Think about permission boundaries, service control policies and so on.\n- It is an official service from AWS, so you can expect this to kept up to date over time.\n- The actual actions are evaluated, but NOT executed. Hence no need for cleaning up resources after testing.\n\n# Quick testing\n\nFor convenience, you can use this tool to quickly test whether a user has a specific permission on a particular resource:\n\n```bash\n$ aws-iam-tester access -u the_user -a 'glue:DeleteTable'\nTest:\nSource: arn:aws:iam::208912673223:user/the_user\nAction: glue:DeleteTable\nResource: *\nResult: allowed\n\nMatched statements:\nPolicy: admin_permissions\nType: IAM Policy\nStart: L3:C17\nEnd: L8:C6\n```\n\nOr to see who has access to a particular resource and action by omitting both `user` and `role`:\n\n```bash\n$ aws-iam-tester access -a \"s3:PutObject\"\n..............\n\nSummary:\n\n| Source | Action | Resource | Decision | Policies |\n|----------------------------------------------------------|--------------|------------|------------|---------------------|\n| arn:aws:iam::XXXXXXXXXXXX:user/the_user | s3:PutObject | * | allowed | admins_permissions |\n| arn:aws:iam::xxxxxxxxxxxx:role/the_role | s3:PutObject | * | allowed | AdministratorAccess |\n```\n\n## Finding out who has access to a particular action/resource combination\n\nIt might be useful to check your highly senstive resources and find out who exactly can access these. \n\n```bash\n$ aws-iam-tester access -a \"s3:PutObject\" -R \"arn:aws:s3:::my-strictly-confidential-data\"\n..............\n\nSummary:\n\n| Source | Action | Resource | Decision | Policies |\n|----------------------------------------------------------|--------------|--------------------------------------------|------------|---------------------|\n| arn:aws:iam::XXXXXXXXXXXX:user/the_user | s3:PutObject | arn:aws:s3:::my-strictly-confidential-data | allowed | admins_permissions |\n| arn:aws:iam::xxxxxxxxxxxx:role/the_role | s3:PutObject | arn:aws:s3:::my-strictly-confidential-data | allowed | AdministratorAccess |\n```\n\n# Account testing\n\nHowever, the initial purpose of this tool is to check an entire account whether there are no users and/or roles having permissons which they should not have.\n\n## Configuration\n\nIn order to run, a configuration of the tests to run is required.\n\nA sample configuration (with only one test) is shown, in various steps.\n\nFirst there is a global section where you define settings which are applied to all tests (unless overruled, more on that later).\n\n```yaml\n---\nuser_landing_account: 0123456789 # ID of AWS Account that is allowed to assume roles in the test account\nglobal_exemptions: # The roles and/or users below will be ignored in all tests. Regular expressions are supported\n- \"^arn:aws:iam::(\\\\d{12}):user/(.*)(ADMIN|admin)(.*)$\"\n- \"^arn:aws:iam::(\\\\d{12}):role/(.*)(ADMIN|admin)(.*)$\"\n- \"^arn:aws:iam::(\\\\d{12}):role/AWSCloudFormationStackSetExecutionRole$\"\n```\n\nThen you define a list of tests, each consisting at least of a set of:\n- actions\n- resources\n- the expected result (should it fail or succeed)\n\n```yaml\n# List of tests to execute. In general the configurations follow the rules of the AWS IAM Policy Simulator.\n# For more information: https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html\ntests: \n- actions: # list of actions to validate\n - \"*:*\"\n - iam:*\n - iam:AddUser*\n - iam:Attach*\n - iam:Create*\n - iam:Delete*\n - iam:Detach*\n - iam:Pass*\n - iam:Put*\n - iam:Remove*\n - iam:UpdateAccountPasswordPolicy\n - sts:AssumeRole\n - sts:AssumeRoleWithSAML\n expected_result: fail # 'fail' or 'succeed'\n resources: # list of resources to validate against\n - \"*\"\n```\n\nRather than using all users and roles (without exemptions) you can also limit your test to a particular set of users and roles.\n\nThe test below does that, including defining a custom context that specifies multi factor authentication is disabled when running the test. By default the context under which the simulations are run assumes MFA is enabled, but you can override that with the `custom_context` element. For more information see the [AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_testing-policies.html).\n\n```yaml\n- actions: # Same list of actions, but now check (with a custom context) whether\n - \"*:*\"\n - iam:*\n - iam:AddUser*\n - iam:Attach*\n - iam:Create*\n - iam:Delete*\n - iam:Detach*\n - iam:Pass*\n - iam:Put*\n - iam:Remove*\n - iam:UpdateAccountPasswordPolicy\n - sts:AssumeRole\n - sts:AssumeRoleWithSAML\n expected_result: fail # 'fail' or 'succeed'\n resources: # list of resources to validate against\n - \"*\"\n limit_to: # check this list for the admin users\n - \"^arn:aws:iam::(\\\\d*):user/(.*)(ADMIN|admin)(.*)$\"\n - \"^arn:aws:iam::(\\\\d*):role/(.*)(ADMIN|admin)(.*)$\"\n # test if the admins are required to use multi factor authentication\n custom_context: \n - context_key_name: aws:MultiFactorAuthPresent\n context_key_values: false\n context_key_type: boolean\n```\n\nOr if you want to do that for **all** tests you can use the `global_limit_to`:\n\n```yaml\n---\nuser_landing_account: 0123456789 # ID of AWS Account that is allowed to assume roles in the test account\nglobal_limit_to: # These roles and/or users below will be u. Regular expressions are supported\n- \"^arn:aws:iam::(\\\\d{12}):user/(.*)(ENGINEER|engineer)(.*)$\"\n- \"^arn:aws:iam::(\\\\d{12}):role/(.*)(SCIENTIST|scientist)(.*)$\"\n```\n\nBelow an example where an additional set of roles is exempt from testing:\n\n```yaml\n- actions: # list of data centric actions\n - redshift:GetClusterCredentials\n - redshift:JoinGroup\n - rds:Create*\n - rds:Delete*\n - rds:Modify*\n - rds-db:connect\n - s3:BypassGovernanceRetention\n - s3:CreateBucket\n - s3:DeleteBucket\n - s3:DeleteBucketPolicy\n - s3:PutBucketAcl\n - s3:PutBucketPolicy\n - s3:PutEncryptionConfiguration\n - s3:ReplicateDelete\n expected_result: fail # 'fail' or 'succeed'\n resources: # list of resources to validate against\n - \"*\"\n exemptions: [\n - \"^arn:aws:iam::(\\\\d{12}):role/(.*)_worker$\" # ignore this for the worker roles\n ]\n```\n\nIf you want to run positive tests (i.e. tests that you need to succeed rather than fail), these `exemptions` don't work that well.\n\nIn that case you can limit your tests to a set of roles and users:\n\n```yaml\n- actions:\n - s3:PutObject\n expected_result: succeed\n resources:\n - \"arn:aws:s3:::my_bucket/xyz/*\"\n limit_to: # if you specify this, test will only be performed for the sources below\n - \"^arn:aws:iam::(\\\\d{12}):role/my_worker$\"\n```\n\n> Note that the exemptions are ignored when using a `limit_to` list.\n\n### Using a dynamic account id in the resource arn\n\nIn case you **need** to specify the `account id` in the resource arn, you can specificy this as follows:\n\n```yaml\n- actions:\n - \"secretsmanager:GetSecretValue\"\n expected_result: succeed\n resources:\n - \"arn:aws:secretsmanager:eu-central-1:{account_id}:secret:my-secret/*\"\n```\n\n### Using regular expressions for user and role matching\n\nRegular expressions can be used when checking the users and/or roles that need to be included in the tests. Hence they are supported for the following elements in the config file:\n\n- limit_to (the filtered list of users/roles to be used for a particular test)\n- global_limit_to (the filtered list of users/roles to be used for all tests)\n- exemptions (the filtered list of users/roles that should be excluded from a particular test)\n- global_exemptions (the filtered list of users/roles that should be excluded from all tests)\n\n> For all other elements, regular expression matching is NOT supported!\n\n## How to use\n\nAssuming you have define a config.yml in your local directory, then to run and write the outputs to the local `./results` directory:\n\n```bash\naws-iam-tester --write-to-file\n```\n\nUsing a specific config file:\n\n```bash\naws-iam-tester --config-file my-config.yml\n```\n\nUsing a specific output location:\n\n```bash\naws-iam-tester --output-location /tmp\n```\n\nOr write to s3:\n\n```bash\naws-iam-tester --output-location s3://my-bucket/my-prefix\n```\n\nInclude only roles that can be assumed by human beings:\n\n```bash\naws-iam-tester --no-include-system-roles\n```\n\n> Note: including system roles does NOT include the aws service roles.\n\nOr print debug output:\n\n```bash\naws-iam-tester --debug\n```\n\nTo run a limited number of evaluations (which helps speeding things up, and avoiding API throttling issues):\n\n```bash\naws-iam-tester --number-of-runs 10\n```\n\nFor more information, run `aws-iam-tester --help` for more instructions.\n\n## Return codes\n\nThe tester returns the following return codes:\n\n- 0 upon successful completion with NO findings\n- 1 upon successful completion with findings\n- 2 (or higher) on failures\n\n## Required permissions\n\nObviously the client has to run under an AWS security context that has sufficient permissions to query the IAM resources and run the simulator.\n\nThe following permissions are needed at the minimum:\n\n```yaml\n- sts:GetCallerIdentity\n- iam:ListAccountAliases\n- iam:ListRoles\n- iam:ListUsers\n- iam:SimulatePrincipalPolicy\n```\n\nAnd if you want to write the output to an s3 location, then obviously you need write access (`s3:PutObject`) to that particular location as well.\n\n## Unit testing\n\n`pytest` is being used for testing the various options.\n\nAs long as the `aws-iam-tester` module is installed, you can run the [tests](./tests).\n\n```console\npytest -vsx\n\n# or, alternatively\npoetry run pytest -vsx\n```\n\nAfter installing `tox`, you can also simply run `$ tox`.",
"bugtrack_url": null,
"license": "MIT",
"summary": "AWS IAM tester - simple command-line tool to check permissions handed out to IAM users and roles.",
"version": "1.0.6",
"project_urls": {
"Documentation": "https://github.com/gercograndia/aws-iam-tester/blob/master/README.md",
"Homepage": "https://github.com/gercograndia/aws-iam-tester",
"Repository": "https://github.com/gercograndia/aws-iam-tester",
"issues": "https://github.com/gercograndia/aws-iam-tester/issues"
},
"split_keywords": [
"aws",
" iam",
" policy",
" tester",
" evaluation",
" simulator"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "9df9bc97ac6ba28280712e74f328d8100e9eb710f7bf48287508feb158a834eb",
"md5": "a4767f4b4b885de19ced0695ef7ce393",
"sha256": "ab990099c533827495bb3e6f7331269d62065afb40d09d78ba8efb76024b8981"
},
"downloads": -1,
"filename": "aws_iam_tester-1.0.6-py3-none-any.whl",
"has_sig": false,
"md5_digest": "a4767f4b4b885de19ced0695ef7ce393",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": "<4.0.0,>=3.7.2",
"size": 16552,
"upload_time": "2024-06-10T09:30:24",
"upload_time_iso_8601": "2024-06-10T09:30:24.746473Z",
"url": "https://files.pythonhosted.org/packages/9d/f9/bc97ac6ba28280712e74f328d8100e9eb710f7bf48287508feb158a834eb/aws_iam_tester-1.0.6-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "ce3fcb4630f49e8fab2d4ccfc644e6914a6d06b75ba6c4fd352e550935b57f67",
"md5": "7f6958fbc9874d751bce75137f6cf30b",
"sha256": "4214cfbf9e844808ae0a068066c7d2752edd4d11e34152e22e6312f97f4a1f9c"
},
"downloads": -1,
"filename": "aws_iam_tester-1.0.6.tar.gz",
"has_sig": false,
"md5_digest": "7f6958fbc9874d751bce75137f6cf30b",
"packagetype": "sdist",
"python_version": "source",
"requires_python": "<4.0.0,>=3.7.2",
"size": 17909,
"upload_time": "2024-06-10T09:30:26",
"upload_time_iso_8601": "2024-06-10T09:30:26.227753Z",
"url": "https://files.pythonhosted.org/packages/ce/3f/cb4630f49e8fab2d4ccfc644e6914a6d06b75ba6c4fd352e550935b57f67/aws_iam_tester-1.0.6.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-06-10 09:30:26",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "gercograndia",
"github_project": "aws-iam-tester",
"travis_ci": false,
"coveralls": false,
"github_actions": true,
"tox": true,
"lcname": "aws-iam-tester"
}
JSON
