Update main.tf

[labtestsubb]

asdfasdf

[prisma-cloud-devsecops]

Prisma Cloud has found errors in this PR ⬇️

[prisma-cloud-devsecops]

  AWS VPC subnets should not allow automatic public IP assignment
    Resource: aws_subnet.eks_subnet2 | Checkov ID: CKV_AWS_130

How to Fix

resource "aws_subnet" "test" {
 ...
+ map_public_ip_on_launch = false
  }

Description

VPC subnet is a part of the VPC having its own rules for traffic.
Assigning the Public IP to the subnet automatically (on launch) can accidentally expose the instances within this subnet to internet and should be edited to 'No' post creation of the Subnet.

[prisma-cloud-devsecops]

  AWS VPC subnets should not allow automatic public IP assignment
    Resource: aws_subnet.eks_subnet1 | Checkov ID: CKV_AWS_130

How to Fix

resource "aws_subnet" "test" {
 ...
+ map_public_ip_on_launch = false
  }

Description

VPC subnet is a part of the VPC having its own rules for traffic.
Assigning the Public IP to the subnet automatically (on launch) can accidentally expose the instances within this subnet to internet and should be edited to 'No' post creation of the Subnet.

[prisma-cloud-devsecops]

  AWS EKS cluster does not have secrets encryption enabled
    Resource: aws_eks_cluster.eks_cluster | Checkov ID: CKV_AWS_58

How to Fix

resource "aws_eks_cluster" "example" {
  ...
  encryption_config {
+    resources = ["secrets"]
    provider {
      key_arn = aws_kms_key.example.arn
    }
  }
  ...
}

Description

This policy identifies AWS EKS clusters that do not have secrets encryption enabled. AWS EKS cluster secrets are, by default, stored unencrypted in the API server's underlying data store (etcd). Anyone with direct access to etcd or with API access can retrieve or modify the secrets. Using secrets encryption for your Amazon EKS cluster allows you to protect sensitive information such as passwords and API keys using Kubernetes-native APIs. It is recommended to enable secrets encryption to ensure its security and reduce the risk of unauthorized access or data breaches.

[prisma-cloud-devsecops]

  AWS Default Security Group does not restrict all traffic
    Resource: aws_vpc.eks_vpc | Checkov ID: CKV2_AWS_12

How to Fix

resource "aws_vpc" "issue_vpc" {
  cidr_block = "10.0.0.0/16"
}

resource "aws_default_security_group" "default" {
  vpc_id = aws_vpc.issue_vpc.id

-  ingress {
-    protocol  = "-1"
-    self      = true
-    from_port = 0
-    to_port   = 0
-  }

-  egress {
-    from_port   = 0
-    to_port     = 0
-    protocol    = "-1"
-    cidr_blocks = ["0.0.0.0/0"]
-  }
}

Description

A VPC comes with a default security group that has an initial setting denying all inbound traffic, allowing all outbound traffic, and allowing all traffic between instances assigned to the security group.
If you do not specify a security group when you launch an instance, the instance is automatically assigned to this default security group.
Security groups are stateful and provide filtering of ingress/egress network traffic to AWS resources.
We recommend that your default security group restricts all inbound and outbound traffic.
The default VPC in every region should have its default security group updated to comply with this recommendation.
Any newly created VPCs will automatically contain a default security group that will need remediation to comply with this recommendation.
Configuring all VPC default security groups to restrict all traffic will encourage least privilege security group development and mindful placement of AWS resources into security groups.
This in-turn reduces the exposure of those resources.

NOTE: When implementing this recommendation, VPC flow logging is invaluable in determining the least privilege port access required by systems to work properly. VPC flow logging can log all packet acceptances and rejections occurring under the current security groups. This dramatically reduces the primary barrier to least privilege engineering, discovering the minimum ports required by systems in the environment.
Even if the VPC flow logging recommendation described is not adopted as a permanent security measure, it should be used during any period of discovery and engineering for least privileged security groups.

[prisma-cloud-devsecops]

  AWS EKS cluster endpoint access publicly enabled
    Resource: aws_eks_cluster.eks_cluster | Checkov ID: CKV_AWS_39

How to Fix

resource "aws_eks_cluster" "disabled" {
  name     = "example"
  role_arn = "aws_iam_role.arn"

  vpc_config {
    subnet_ids = ["subnet-12345"]

    endpoint_public_access = False
  }
}

Description

Amazon EKS creates an endpoint for any managed Kubernetes API server to communicate with the cluster.
This API server endpoint is public to the internet by default.
Access to it should be regulated using AWS IAM and native Kubernetes RBAC.
We recommended that your Kubernetes API server remains private so that all communication between worker nodes and APIs stays within your VPC.
If public access is needed, restrict the IP addresses that can access your API server from the internet to reduce the potential attack surface.

[prisma-cloud-devsecops]

  AWS EKS cluster security group overly permissive to all traffic
    Resource: aws_eks_cluster.eks_cluster | Checkov ID: CKV_AWS_38

How to Fix

##Option 1
resource "aws_eks_cluster" "disabled" {
  name     = "example"
  role_arn = "aws_iam_role.arn"

  vpc_config {
    subnet_ids = ["subnet-12345"]

    endpoint_public_access = False
  }

##Option 2:
resource "aws_eks_cluster" "restricted" {
  name     = "example"
  role_arn = "aws_iam_role.arn"

  vpc_config {
    subnet_ids = ["subnet-12345"]

    public_access_cidrs = ["10.0.0.0/16"]
  }
}
}

Description

Amazon EKS creates an endpoint for any managed Kubernetes API server to communicate with the cluster.
By default, this API server endpoint is public to the internet.
Access to it should be regulated using AWS IAM and native Kubernetes RBAC.
We recommend that your Kubernetes API server remains private so that all communication between worker nodes and APIs stays within your VPC.
If public access is needed, at a minimum, restrict the IP addresses that can access your API server from the internet to reduce the potential attack surface.
Ensure your Amazon EKS public endpoint is not accessible to 0.0.0.0/0.