{"id":13602702,"url":"https://github.com/jtyers/aws-policy-generator","last_synced_at":"2025-06-22T00:06:57.942Z","repository":{"id":37425813,"uuid":"500874644","full_name":"jtyers/aws-policy-generator","owner":"jtyers","description":"Simple CLI-driven and YAML-driven AWS policy generation","archived":false,"fork":false,"pushed_at":"2022-08-05T14:21:57.000Z","size":84,"stargazers_count":8,"open_issues_count":0,"forks_count":0,"subscribers_count":3,"default_branch":"main","last_synced_at":"2025-06-08T21:57:50.097Z","etag":null,"topics":["aws","iam","security"],"latest_commit_sha":null,"homepage":"","language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/jtyers.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2022-06-07T14:26:40.000Z","updated_at":"2025-04-07T22:33:53.000Z","dependencies_parsed_at":"2022-08-19T06:11:22.941Z","dependency_job_id":null,"html_url":"https://github.com/jtyers/aws-policy-generator","commit_stats":null,"previous_names":[],"tags_count":7,"template":false,"template_full_name":null,"purl":"pkg:github/jtyers/aws-policy-generator","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jtyers%2Faws-policy-generator","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jtyers%2Faws-policy-generator/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jtyers%2Faws-policy-generator/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jtyers%2Faws-policy-generator/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/jtyers","download_url":"https://codeload.github.com/jtyers/aws-policy-generator/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/jtyers%2Faws-policy-generator/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":261212484,"owners_count":23125583,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws","iam","security"],"created_at":"2024-08-01T18:01:34.500Z","updated_at":"2025-06-22T00:06:52.916Z","avatar_url":"https://github.com/jtyers.png","language":"Python","funding_links":[],"categories":["aws"],"sub_categories":[],"readme":"# aws-policy-generator\n\naws-policy-generator is a utility that allows for simple generation of IAM policies.\n\n## Features\n\naws-policy-generator allows you to generate list-only, read-only, read-write or full-access policies for any AWS service via the command-line or a YAML config file.\n\nI wrote it for those instances where you want a simple, non-repetitive way of granting broad-brush permissions to IAM roles. Generally, this tool works best for granting access to roles used by human users, particularly in dev environments, and not application roles. For applications you should write specific least-privilege policies to ensure any compromise of the application does not threaten other AWS resources.\n\n`aws-policy-generator` is powered by my [aws-iam-utils](https://github.com/jtyers/aws-iam-utils) library, which is a Swiss-army knife for IAM policy generation, analysis and manipulation. If you need a programmatic way of working with policies, I recommend you use the library directly.\n\n## Installation\n\nAs easy as:\n\n```\npip install aws-policy-generator\n```\n\n## Usage\n\nThere are two ways to use this tool: directly via CLI, or via a YAML file. You can freely combine both approaches but when starting out I recommend choosing one or the other.\n\n### CLI usage\n\nYou can get full help by running `aws-policy-generator --help`. Here are some examples to get you started. All of the command-line flags below can be combined or repeated to get the results you need.\n\nTo generate a policy granting full access to some services, for example IAM and S3:\n```shell\n# you can use -a instead of --full-access\n\u003e\u003e\u003e aws-policy-generator --full-access iam --full-access s3\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Resource\": \"*\",\n      \"Action\": [\n        \"iam:*\",\n        \"s3:*\"\n      ]\n    }\n  ]\n}\n```\n\nTo grant read-only access, use `--read`/`-r`, list-only access use `--list`/`-l` and write access is `--write`/`-w`. Granting write will also grant read and list, and granting read will also grant list.\n\nWhen using `--list`, `--read` or `--write` you can scope the permissions granted to specific types of resources (or ARN types). For example, suppose you wanted to grant someone access to manipulate IAM instance profiles only, you would do:\n\n```shell\n# you can use -a instead of --full-access\n\u003e\u003e\u003e aws-policy-generator --full-access iam:instance-profile\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Resource\": \"*\",\n      \"Action\": [\n        \"iam:addroletoinstanceprofile\",\n        \"iam:createinstanceprofile\",\n        \"iam:deleteinstanceprofile\",\n        \"iam:getinstanceprofile\",\n        \"iam:listinstanceprofiletags\",\n        \"iam:listinstanceprofiles\",\n        \"iam:removerolefrominstanceprofile\",\n        \"iam:taginstanceprofile\",\n        \"iam:untaginstanceprofile\"\n      ]\n    }\n  ]\n}\n```\n\nYou can also add specific actions to a policy:\n\n```shell\n# you can use -A instead of --action\n\u003e\u003e\u003e aws-policy-generator --action s3:ListMyBuckets\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Resource\": \"*\",\n      \"Action\": [\n        \"s3:listmybuckets\"\n      ]\n    }\n  ]\n}\n\n(Note: please read the **Important: wildcard-ARN actions** section below.)\n```\n\nSometimes the policies generated will be quite long. Depending on the type of policy you're trying to create, you may hit the AWS [policy length limits](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_iam-quotas.html). To help mitigate this issue, `aws-policy-generator` has support for shortening policies.\n\n```shell\n\u003e\u003e\u003e aws-policy-generator -w iam -r s3 -w ec2 -w lambda --auto-shorten\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Resource\": \"*\",\n      \"Action\": [\n        \"s3:listmybuckets\"\n      ]\n    }\n  ]\n}\n```\n\n### YAML usage\n\nFor more complex policies, or automated usage (for example, my clients often use this as part of an infrastructure-as-code pipeline), YAML is often better and, of course, can be committed to Git. Here's example YAML code to give you a flavour.\n\n(Note: please read the **Important: wildcard-ARN actions** section below.)\n\n```yaml\n# aws-policy-generator uses a simple format for policy generation.\n#\n# Under the 'policies' key there can be either 'service' or 'action' items.\n#\n# See below for examples.\n\npolicies:\n    # Adds permissions for all of the IAM service. Only list\n    # permissions are granted, so read/write/tagging/permissions related\n    # actions are excluded.\n    - service: iam\n      access_level: list\n\n    # Adds permissions for the instance resource type in EC2.\n    # Write, Read and List permissions are granted, but tagging/permissions\n    # actions are excluded.\n    - service: ec2\n      access_level: write\n      resource_type: instance\n\n    # Adds Read and List access to all of AWS Lambda.\n    - service: lambda\n      access_level: read\n\n    # Adds full access to S3 (i.e. s3:*)\n    - service: s3\n      access_level: all\n\n    # You can also add multiple services at once\n    - access_level: read\n      service:\n        - lambda\n        - s3\n        - iam\n\n    # Specific resource types/ARN types can be specified too\n    - access_level: all\n      service: iam\n      resource_type: instance-profile\n    \n    # ...and can be specified as a list if multiple are needed\n    - access_level: all\n      service: iam\n      resource_type:\n        - instance-profile\n        - role\n        - policy\n\n    # Instead of service-wide grants, you can add specific actions...\n    #\n\n    # Adds the s3:ListBucket action permission, scoped to only\n    # the given resource.\n    - action: s3:ListBucket\n      resource: arn:aws:s3:::my-test-bucket\n\n    # Same as above, but with multiple resources\n    - action: s3:ListBucket\n      resource:\n        - arn:aws:s3:::my-test-bucket\n        - arn:aws:s3:::my-test-bucket/*\n```\n\n### Important: wildcard-ARN actions\n\nMost IAM actions can be applied to a specific `Resource`. For example, `s3:PutObject` can be given `Resource: *`, or a specific object/bucket ARN. There are however some actions that cannot be constrained in this way and only make sense with `Resource: *`. For example, `ssm:DescribeParameters` and `s3:ListAllMyBuckets` can only be used with `Resource: *`, it doesn't make sense to use them with anything else.\n\nWe call these *wildcard-ARN actions*.\n\nDue to the way the IAM database is constructed, it's impossible for `aws-iam-utils` (the library `aws-policy-generator` uses under the hood) to link wildcard-ARN actions to resource types. This means for example that if you call\n\n```shell\naws-policy-generator --read ssm:parameter\n```\n\nOr you use the following YAML file\n\n```yaml\npolicies:\n  - access_level: read\n    service: ssm:parameter\n```\n\n...the generated policy **will not include `ssm:DescribeParameters` by default**, even though that is clear an action related to the `ssm:parameter` resource type.\n\nTo get around this limitation, we've added a new setting. If you specify the `--include-service-wide-actions` argument (or `-S` for shorthand):\n\n```shell\naws-policy-generator --read ssm:parameter --include-service-wide-actions\n```\n\nOr include `include_service_wide_actions` in your YAML file:\n\n```yaml\npolicies:\n  - access_level: read\n    service: ssm:parameter\n    include_service_wide_actions: true\n```\n\nThen the generated policy will include all wildcard-ARN actions for that service. This feature is turned off by default as it is non-intuitive if you are trying to craft least-privilege policies; it is typically required for specific use cases such as using the AWS console or using some Terraform resources.\n\nIn YAML you can also include a file-wide `include_service_wide_actions` setting like so:\n\n```yaml\noptions:\n  include_service_wide_actions: true\n\npolicies:\n  - access_level: read\n    service: ssm:parameter\n\n    # inherits include_service_wide_actions from options block above\n  \n  - access_level: read\n    service: s3:bucket\n\n    include_service_wide_actions: false  # overrides the options block\n```\n\nThis will cause all policies, unless otherwise specified, to include wildcard-ARN actions for that service.\n\n# Licence\n\nMIT\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjtyers%2Faws-policy-generator","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fjtyers%2Faws-policy-generator","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fjtyers%2Faws-policy-generator/lists"}