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

False positive: CKV_AWS_19: "Ensure all data stored in the S3 bucket is securely encrypted at rest" #452

Closed
ismailyenigul opened this issue Jul 17, 2020 · 4 comments
Assignees

Comments

@ismailyenigul
Copy link
Contributor

Describe the bug

checkov fails on encryption enabled bucket

To Reproduce
Steps to reproduce the behavior:

check: CKV_AWS_19: "Ensure all data stored in the S3 bucket is securely encrypted at rest"
	FAILED for resource: aws_s3_bucket.my
	Guide: https://docs.bridgecrew.io/docs/s3_14-data-encrypted-at-rest
	File: /my/golden/s3.tf:1-18

		1  | resource "aws_s3_bucket" "my" {
		2  |   bucket = "my-${lower(var.environment)}-my-${lower(var.my)}"
		3  |   acl    = "private"
		4  |   # Delete S3 Bucket even it has some objects in it
		5  |   force_destroy = "true"
		6  | 
		7  |   server_side_encryption_configuration {
		8  |     rule {
		9  |       apply_server_side_encryption_by_default { sse_algorithm = "AES256" }
		10 |     }
		11 |   }
		12 | 
		13 |   versioning {
		14 |     enabled = false
		15 |   }
		16 | 
		17 | 
		18 | }

 
Version:

checkov -v
1.0.447
@nimrodkor
Copy link
Contributor

Hi @ismailyenigul !

I think the problem is not a bad check. When scanning this block:

resource "aws_s3_bucket" "my" {
  bucket = "my-${lower(var.environment)}-my-${lower(var.my)}"
  acl    = "private"
  # Delete S3 Bucket even it has some objects in it
  force_destroy = "true"

  server_side_encryption_configuration {
    rule {
      apply_server_side_encryption_by_default { 
        sse_algorithm = "AES256" 
      }
    }
  }

  versioning {
    enabled = false
  }
}

The difference is that the sse_algorithm is in it's own line - and the result is "PASSED" for me.
We know of this issue and plan to handle it soon. Thanks for reporting!

@ismailyenigul
Copy link
Contributor Author

Cool thanks @nimrodkor

@ismailyenigul
Copy link
Contributor Author

ismailyenigul commented Jul 17, 2020

Another check about image pull policy.
I think this check should failed if the latest tag is used.
If we are not using latest tag, it should not be an issue no?

Check: CKV_K8S_15: "Image Pull Policy should be Always"
	FAILED for resource: Deployment.calico-typha-horizontal-autoscaler.kube-system (container 0)
	Guide: https://docs.bridgecrew.io/docs/bc_k8s_14
	File: /calico/staging/calico/calico.yaml:686-699

		686 |         - image: k8s.gcr.io/cluster-proportional-autoscaler-amd64:1.7.1
		687 |           name: autoscaler
		688 |           command:
		689 |             - /cluster-proportional-autoscaler
		690 |             - --namespace=kube-system
		691 |             - --configmap=calico-typha-horizontal-autoscaler
		692 |             - --target=deployment/calico-typha
		693 |             - --logtostderr=true
		694 |             - --v=2
		695 |           resources:

@schosterbarak
Copy link
Contributor

solved on #477

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

No branches or pull requests

3 participants