-
-
Notifications
You must be signed in to change notification settings - Fork 225
upstream eks folder
#497
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
upstream eks folder
#497
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bridgecrew has found errors in this PR ⬇️
| ] | ||
| } | ||
|
|
||
| data "aws_iam_policy_document" "github_actions_iam_policy" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ensure IAM policies does not allow write access without constraint
Resource: aws_iam_policy_document.github_actions_iam_policy | ID: BC_AWS_IAM_57
How to Fix
data "aws_iam_policy_document" "example" {
statement {
sid = "1"
effect = "Allow"
actions = [
"s3:*"
]
resources = [
"foo",
]
}
}Description
This policy allows actions that permit modification of resource-based policies or can otherwise can expose AWS resources to the public via similar actions that can lead to resource exposure.For example:
1 - s3:PutBucketPolicy, s3:PutBucketAcl, and s3:PutObjectAcl grant permissions to modify the properties of S3 buckets or objects for new or existing objects in an S3 bucket, which could expose objects to rogue actors or to the internet.
2 - ecr:SetRepositoryPolicy could allow an attacker to exfiltrate container images (which sometimes unintentionally contain secrets and non-public information), tamper with container images, or otherwise modify.
3 - iam:UpdateAssumeRolePolicy could allow an attacker to create a backdoor by assuming a privileged role in the victim account from an external account.
The ability to modify AWS Resource Access Manager, which could allow a malicious actor to share a VPC hosting sensitive or internal services to rogue AWS accounts
Attackers can easily exploit Resource Exposure permissions to expose resources to rogue users or the internet, as shown by endgame, an AWS pentesting tool that was also released by Salesforce.
For more info, visit cloudsplaning documentation
https://cloudsplaining.readthedocs.io/en/latest/glossary/resource-exposure/
🎉 Fixed by commit c44a569 - update variables.tf for components to point to eks/cluster
| ] | ||
| } | ||
|
|
||
| data "aws_iam_policy_document" "github_actions_iam_policy" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ensure IAM policies do not allow data exfiltration
Resource: aws_iam_policy_document.github_actions_iam_policy | ID: BC_AWS_IAM_55
How to Fix
data "aws_iam_policy_document" "example" {
statement {
sid = "1"
effect = "Allow"
actions = [
"lambda:CreateFunction",
"lambda:CreateEventSourceMapping",
"dynamodb:CreateTable",
]
resources = [
"*",
]
}
}Description
Data Exfiltration actions allow certain read-only IAM actions without resource constraints, such as s3:GetObject, ssm:GetParameter*, or secretsmanager:GetSecretValue.1 - Unrestricted s3:GetObject permissions has a long history of customer data leaks
2 - ssm:GetParameter* and secretsmanager:GetSecretValue are both used to access secrets.
3 - rds:CopyDBSnapshot and rds:CreateDBSnapshot can be used to exfiltrate RDS database contents.
For more info, visit cloudsplaning documentation
https://cloudsplaining.readthedocs.io/en/latest/glossary/data-exfiltration/
🎉 Fixed by commit c44a569 - update variables.tf for components to point to eks/cluster
Nuru
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a bit of a regression in actions-runner-controller, and maybe elsewhere, but we will sort it out.
what
why
references
alb-controller-ingress-groupcomponent upstream #491 - superseded