Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix codebuild policy length #774

Merged
merged 2 commits into from
Sep 28, 2023
Merged

Fix codebuild policy length #774

merged 2 commits into from
Sep 28, 2023

Conversation

noah-paige
Copy link
Contributor

Feature or Bugfix

  • Bugfix

Detail

  • There is a limit of 10,240 characters aggregate across all inline policies that are able to be attached to an IAM Role
    • By default, codebuild adds its own IAM permission statements as inline policies to the attached execution role to the Build Project unless otherwise specified
    • On certain deployment configurations we will exceed the 10,240 character limit because we use the same IAM role for many CodeBuild Steps and each CodeBuild Project will add addition IAM inline statements

In this PR, to resolve we:

  • Add the missing IAM permissions that CodeBuild would add by default to the IAM Role
  • Switch the IAM policy we add to the IAM Role from inline to customer managed policy (as a best practice)
  • Pass a copy of the IAM Role with .without_policy_updates() to each CodeBuildStep to prevent CodeBuild from adding additional permissions statements and exceeding the character limit

Relates

Security

Please answer the questions below briefly where applicable, or write N/A. Based on
OWASP 10.

  • Does this PR introduce or modify any input fields or queries - this includes
    fetching data from storage outside the application (e.g. a database, an S3 bucket)?
    • Is the input sanitized?
    • What precautions are you taking before deserializing the data you consume?
    • Is injection prevented by parametrizing queries?
    • Have you ensured no eval or similar functions are used?
  • Does this PR introduce any functionality or component that requires authorization?
    • How have you ensured it respects the existing AuthN/AuthZ mechanisms?
    • Are you logging failed auth attempts?
  • Are you using or adding any cryptographic features?
    • Do you use a standard proven implementations?
    • Are the used keys controlled by the customer? Where are they stored?
  • Are you introducing any new policies/roles/users?
    • Have you used the least-privilege principle? How?

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@noah-paige noah-paige linked an issue Sep 22, 2023 that may be closed by this pull request
@noah-paige noah-paige self-assigned this Sep 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Upgrade to v1.6.2 fails due to inability for pipeline to self-mutate
2 participants