Forem: Rohit Salecha

My Cloud Desktop

Rohit Salecha — Thu, 16 Mar 2023 16:33:15 +0000

Motivation

For quite some time I've primarily been using *nix terminal (Ubuntu-WSL2 and MacOS) and VSCode for most of my research/pentest and day-to-day work. I like to keep my base machine as clean as possible with the least number of softwares needed like just the CLI and browser. I would use this bare-minimum software to connect to my cloud machine where most of my softwares/services are installed like nmap,metasploit,awscli,terraform etc ...

But the problem was that I the requirement for this machine was quite intermittent and sporadic, it was never constant. So each time I needed the machine, I'd login to my console,start it,change my IP in the laptop and then go about doing my job. This was quite cumbersome and tedious and manual.

Also, I didn't want to remember the IP address everytime I spin up, just the Domain name as it becomes easier to configure domain names on internet than IP addresses.

Hence, out of pure laziness I decided to write a terraform + ansible script (a combination I'd been wanting to work on for a long long long long long time) that does the following

Spins up an EC2 Ubuntu Focal (❤️)
Configures it with my most used softwares - VSCode,NMap,Nuclei,Semgrep,awscli and some pentest tools.
Configure my Duck DNS domain name (rohit-salecha.duckdns.org) with the IP Address of the EC2 with LetsEncrypt Certificate.
Have a Source IP restriction such that it is accessible only from a specific IP Address like my home ip.

Pre-Requisites

An AWS account with credentials configured in CLI
- https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html
DuckDNS Account and Domain - https://www.duckdns.org/
- Please read through the Terms and Conditions before using this service https://www.duckdns.org/tac.jsp
Terraform binary installed
- https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli
- Minimum version 1.4

Warnings

Some important warnings before you start using the code

Running the scripts in this blog will charge you money as we are downloading quite a lot of content to the cloud machine and the bare minimum 4 GB RAM machine is needed which doesn't fall into free tier.
Opening up of port 80 is necessary for the entire internet as it's needed for LetsEncrypt validation. https://letsencrypt.org/docs/allow-port-80/
Port 53 is also open but no service is currently configured to listen on it. You can start your own DNS server for SSRF pingbacks.
Any abuse of the code and the service provided is solely the responsibility of the user.

Duck DNS

Duck DNS is a free service where you can create a sub-domain of your choice .duckdns.org and they have a simple curl command that allows you to update the DNS A record with the IP Address of the EC2 machine as shown below.

https://www.duckdns.org/update?domains={YOURVALUE}&token={YOURVALUE}[&ip={YOURVALUE}][&ipv6={YOURVALUE}][&verbose=true][&clear=true]

I've implemented this as a curl command in my terraform code which automatically reads the IP from the EC2 machine and updates the DNS record.

In order to use this, you'll first need to sign up, create a sub-domain of your choice and save the token provided as shown below.

Any abuse of the code and the service provided is solely the responsibility of the user.

Github Clone

Clone the Github repository

https://github.com/salecharohit/my-cloud-desktop.git

cmd> git clone https://github.com/salecharohit/my-cloud-desktop.git
cmd> cd my-cloud-desktop
cmd> mv terraform.auto.tfvars.bak terraform.auto.tfvars

Once clone is done edit the terraform.auto.tfvars file and configure the following required variables with the necessary data.

# Region of deployment of EC2, its recommended to deploy closest possible to avoid latency
region                      = "ap-south-1"
# Recommneded is t3.medium or select from here https://instances.vantage.sh/
instance_type               = "t3.medium"
# Whether to apply source IP restrictions for SSH Access. 
# IP Address from where you are executing the terraform script will be used to restrict access to port 443 and 22.
# Check file networking.tf
apply_source_ip_restriction = true
duckdns_token               = "XXXXXXXXXXXXXXXXXXXXXXXXXX"
duckdns_hostname            = "XXXXXXXXXXXX.duckdns.org"
email                       = "XXXXXX@XXXXXX.com"
vscode_password             = "XXXXXXXXXXXXXXXXXXXXXX"

NOTE : The terraform.auto.tfvars is part of your .gitignore hence any changes made in this file will not be comitted in your remote repository and will only remain on your machine.

Terraform Execution

Once everything is set its time to execute our code using the commands as shown below.

cmd> export AWS_PROFILE=<your-profile>
cmd> cd my-cloud-desktop
cmd> terraform init
cmd> terraform validate
cmd> terraform apply --auto-approve

XXXXXXXXXXXXXXX------SNIPPED-------XXXXXXXXXXXXXXXXXXXXX
Apply complete! Resources: 43 added, 0 changed, 0 destroyed.

Outputs:

server_ip = "15.206.158.91"

Accessing VSCode in browser

Once the apply is complete navigate to domain name you've configured and enter the password as shown in the screen below.

After entering the password we can start using VSCode as shown below.

Accessing Terminal from VSCode ex : Metasploit

Accessing Server through SSH

The code generates a private SSH key called ubuntu_key.pem in the keypair.tf file and stores it in your local system. The .gitignore file ignores all *.pem files and hence this will not be committed to your Git history and usable only from the local machine you are operating from.

Accessing the server is quite simple.

cmd> ssh -i ubuntu_key.pem ubuntu@<your-duckdns-domain>

Or you could also save it in an ssh config as which is something that you no longer need to change now. Just ensure the path-to-ubuntu-key is configured correctly.

Host cloud-desktop
HostName <your-domain>.duckdns.org
Port 22
User ubuntu
IdentitiesOnly yes
IdentityFile <path-to-ubuntu-key>/ubuntu_key.pem

Accessing Miscellaneous Services

In case you wish to access any GUI service within the server that's running on a port like 8080, but you donot wish to open it up on the internet then simply execute the following commands.

ssh -i ubuntu_key.pem ubuntu@<your-duckdns-domain> -L 8081:localhost:8080
curl http://localhost:8081

Using the above command you are instructing that port 8081 on your local computer needs to be forwarded to port 8080 on the EC2 server. This forwarding of the traffic is now happening over a secure channel and you donot have to open up your machine to the internet.

Terraform Destroy

To destroy the app simply fire the below command

cmd> export AWS_PROFILE=<your-profile> 
cmd> terraform destroy --auto-approve

AWS EKS Playground using Terraform

Rohit Salecha — Wed, 22 Feb 2023 10:44:49 +0000

Motivation

This blog is a leaf out of my book Practical GitOps where I discuss how one can manage AWS infrastructure using Terraform and orchestrate it with Github Actions.

As part of my book I’ve deployed a working SpringBoot application on AWS EKS as a base for explaining everything around it right from AWS Organizations to Secrets Management, IRSA to setting up an observability stack. This blog is all about that base application and the surrounding infrastructure.

Also, with the entire cloud and cloud native ecosystem having so many different tools I needed a playground which I could set up quickly and then destroy. This project gives me that flexibility so that I can quickly set up an EKS(kubernetes) environment and then play around with various different tools and its obvious integration with AWS.

Link to buy the book and how to get a 20% discount coupon code is shared towards the end of the post

Architecture

The above diagram shows a high-level architecture of the base infrastructure that we are doing to deploy.Other than Route53, rest everything will be set up using Terraform in this blog. A brief description follows

We’ll be creating a VPC with three subnets namely: public,private and database.
Public subnet will have resources that need to be externally facing like the AWS Application Load Balancer which will be spun up as an Ingress Controller.
Our Kubernetes Nodes (managed by us) will be spun up in the Private subnet having and will not be accessible from the internet.
The Master node of Kubernetes is completely managed by AWS and hence we have no control over its placement. However the Kubernetes API-endpoint will be available over 443 on the internet for authentication to EKS cluster.
Our PostgreSQL Database is living in the database subnet which is a separate subnet having additional security controls.
The connectivity between the Public Subnet and the Private subnet is established using a NAT gateway. There is no NAT gateway to route traffic between Database Subnet and Public subnet hence it is sufficiently isolated.
We’ll be utilizing AWS Certificate Manager (ACM) to generate the public SSL certificates for our application. Our Terraform code will not only generate the certificates but also validate the certificates by creating necessary Route53 name records.

Pre-Requisites

In order to follow along this blog you’ll need the following

An AWS account with credentials configured in CLI
- https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html
A top level domain/subdomain name
Kubectl Utility - Kubectl is the default utility to talk with the kubernetes service that we’ll be spinning up using Terraform. Recommended to have version 1.20 or above.
- https://kubernetes.io/docs/tasks/tools/
Terraform binary installed
- https://developer.hashicorp.com/terraform/tutorials/aws-get-started/install-cli
Your favorite Code editor

WARNING : Running the scripts in this blog will charge you some amount of money as AWS EKS and other services here are not under the free-tier. Also, this is only a demo project. Exercise caution and encourage you to learn more about it before trying it out.

AWS Route53

First thing we need to do is create a Route53 Hosted Zone with a domain/subdomain of your choice. I am demonstrating using a sub-domain that is ekspg.rohitsalecha.com. You could use a primary domain as well but the nameserver configuration will need to be tweaked accordingly.

The below command will help you in creating a route53 hosted zone from CLI and make a note of the NameServers as shown below.

“--caller-reference” is a random number so the best bet is to use your current timestamp as shown.

cmd> export AWS_PROFILE=<your-profile>
cmd> aws route53 create-hosted-zone --name ekspg.rohitsalecha.com \
    --caller-reference 2023-02-21-24:35

{
XXXXXXXXXXXXXXX------SNIPPED-------XXXXXXXXXXXXXXXXXXXXX
    "DelegationSet": {
        "NameServers": [
            "ns-537.awsdns-03.net",
            "ns-449.awsdns-56.com",
            "ns-1848.awsdns-39.co.uk",
            "ns-1415.awsdns-48.org"
        ]
    }
}

Configuring NameServers

The command output provides 4 different Nameserver values that need to be configured with your DNS provider depending on whether you are configuring a Top-level domain like rohitsalecha.com or a subdomain like ekspg.rohitsalecha.com

If you have GoDaddy as your DNS provider then follow this guide for Top-Level Domains https://in.godaddy.com/help/change-nameservers-for-my-domains-664

For subdomain in GoDaddy this is how you can add a NS as a record https://in.godaddy.com/help/add-an-ns-record-19212

Since I am using a Subdomain this is how I configured my NS records provided by the hosted zone command fired above.

Once your DNS configuration is done do give it a check on https://dnschecker.org/ as shown below.

Only once all is green move on to the next steps. Give it atleast 30 mins to propogate

Github Clone

Clone the Github repository

https://github.com/salecharohit/eks-playground

Open the repository in your favorite code editor and open the file infra/terraform.auto.tfvars as shown below.

File: infra/terraform.auto.tfvars
{
XXXXXXXXXXXXXXX------SNIPPED-------XXXXXXXXXXXXXXXXXXXXX

33: 
34: /********** EKS Module ***************/
35: 
36: eks_version    = "1.21"
37: instance_types = ["t3.medium","t3.small"]
38: 
39: /********** Global Variables ***************/
40: org_name = "ekspg"
41: domain   = "ekspg.rohitsalecha.com"

We need to modify the value domain on Line41 as shown above pointing to the domain that you’ve setup in the earlier section.

NOTE: Feel free to modify the above parameters as you see fit provided you know what you are doing.

Terraform Execution

Once the modification of the domain name is done, its time to execute our code using the commands as shown below.

cmd> export AWS_PROFILE=<your-profile>
cmd> cd eks-playground/infra
cmd> terraform init
cmd> terraform validate
cmd> terraform plan
cmd> terraform apply --auto-approve

XXXXXXXXXXXXXXX------SNIPPED-------XXXXXXXXXXXXXXXXXXXXX
Apply complete! Resources: 88 added, 0 changed, 0 destroyed.

Outputs:

cluster_name = "ekspg-us-east-1-dev"
region = "us-east-1"

Accessing Application

After executing Terraform apply it’ll take upto 20-25 minutes to spin up the entire application+infrastructure. Once the Apply Complete message is shown , wait for 5 minutes more for the Load Balancer to warm up and our site should start functioning and accessible as shown below

https://ekspg.rohitsalecha.com

Accessing through kubectl

cmd> export AWS_PROFILE=<your-profile>
cmd> REGION=$(terraform output -raw region)
cmd> CLUSTER=$(terraform output -raw cluster_name)
cmd> aws eks --region $REGION update-kubeconfig --name $CLUSTER

Added new context arn:aws:eks:us-east-1:26XXXXXXXXX23:cluster/ekspg-us-east-1-prod to /Users/XXXXXXXXXXX/.kube/config

cmd> kubectl get nodes

NAME                          STATUS   ROLES    AGE   VERSION
ip-10-0-12-238.ec2.internal   Ready    <none>   14m   v1.21.14-eks-48e63af
ip-10-0-13-155.ec2.internal   Ready    <none>   14m   v1.21.14-eks-48e63af

Terraform Destroy

To destroy the app simply fire the below command

cmd> export AWS_PROFILE=<your-profile> 
cmd> terraform destroy --auto-approve

Destroy Hosted Zone

If the hosted zone is not needed destroy that too as it costs 0.5$ per month

cmd> export AWS_PROFILE=<your-profile> 
cmd> aws route53 list-hosted-zones

{
    "HostedZones": [
        {
            "Id": "/hostedzone/Z0649256M3CSJUPI94TE",
            "Name": "ekspg.rohitsalecha.com.",
            "CallerReference": "2023-02-21-24:35",
            "Config": {
                "PrivateZone": false
            },
            "ResourceRecordSetCount": 2
        }
    ]
}

cmd> aws route53 delete-hosted-zone --id Z0649256M3CSJUPI94TE

Multi-Environment Configuration

If you’d like to configure multiple environments like dev,staging etc … then this script allows you to modify the same in _infra/variables.tf _ as shown below.

File: infra/variables.tf

3: 
4: variable "environment" {
5:   description = "The Deployment environment"
6:   type        = string
7:   default     = "prod"
8: }
9:

Default value is configured as “prod” however the same can be overridden in the infra/terraform.auto.tfvars file as dev or staging.

The script shall automatically check which environment is configured and also update the Route53 domain. As an example, I modified the environment variable as “dev” and once I started the application I got the URL as shown below.

https://dev.ekspg.rohitsalecha.com/

This magic is happening in this script between Line10-16 as shown below

File: infra/dns.tf

10: locals {
11: 
12:   staging_url = var.environment == "staging" ? "staging.${var.domain}" : ""
13:   prod_url    = var.environment == "prod" ? "${var.domain}" : ""
14:   dev_url     = var.environment == "dev" ? "dev.${var.domain}" : ""
15: 
16:   url = coalesce(local.staging_url, local.prod_url, local.dev_url)
17: 
18: }

What Next ?

As can be seen we deployed the SpringBoot app in the “app” folder which is dockerized as “salecharohit/practicalgitops“ on hub.docker.com.

This app can be changed in the file infra/app.tf as shown below.

File: infra/app.tf
24: 
25: resource "kubernetes_deployment_v1" "app" {
XXXXXXXXXXXXXXX------SNIPPED-------XXXXXXXXXXXXXXXXXXXXX
49: 
50:       spec {
51:         container {
52:           image = "salecharohit/practicalgitops"
53:           name  = var.org_name
54:           env {
55:             name  = "DB_PORT"
56:             value = "5432"
57:           }
58:           env {
59:             name  = "DB_HOST"
60:             value = module.pgsql.db_instance_address
61:           }
62:           env {
63:             name  = "DB_NAME"
64:             value = var.db_name
65:           }
66:           env {
67:             name  = "DB_USERNAME"
68:             value = var.db_user_name
69:           }
70:           env {
71:             name  = "DB_PASSWORD"
72:             value = module.ssmr-db-password.ssm-value
73:           }

Line 52 is where the docker image location needs to be modified. Do configure the remaining parameters as shown between L54-73 as environment variables which will be very specific to your app.

For More AWS EKS specific use-cases/scenarios like installing Karpenter,working with secrets store etc … to check out this repo , it’s awesome and well maintained.

https://github.com/aws-ia/terraform-aws-eks-blueprints

Shameless Plug

Using this setup as a base I am discussing the following in my book Practical GitOps - Infrastructure Management using AWS,Terraform and Github Actions.

CI/CD and Multi-Environment

Orchestrate the entire CI/CD pipeline for Docker build and Terraform Deployment in Github Actions.
Managing the state of Terraform in a multi-environment configuration like dev,staging and prod.

Authentication and Access Management

Setting Up AWS Organisations with different OUs for environments like dev,staging,production and identity.
Configuring all users in a single identity account and creating IAM Roles for them in the respective dev, staging and prod accounts for them to assume with full RBAC.
Creating Kubernetes RBAC by aligning IAM Roles with specific k8s groups. So an engineer in dev account gets admin in k8s but in prod account the same engineer gets only read only. Accessing Kubernetes through kubcectl only by assuming the specific IAM Role that user has been given.
Implementing IRSA(IAM Roles and Service Account) through Terraform and attaching limited identity/privileges to k8s pods.

Security

Creating secrets in AWS Secrets Manager and loading them onto K8s Pods using "Secrets Store CSI Driver" by leveraging IRSA
Implementing basic security controls on EC2 Nodes created by EKS like IMDSv2 ,Encrypting EBS drives and encrypting k8s Secrets using AWS KMS keys.
Integrating Checkov using Github Actions and spooling results in PRs
Creating Route53 DNS Zones for each of the dev, staging and prod accounts
Implementing Service Control Policies that lock regions of deployment,Ensuring that only encrypted EBS and RDS are deployed in staging/production,Disabling user creation in all accounts except identity,Restricting the instance types that can be created in Development OU

Observability

Centralizing CloudTrail into master account by leveraging and creating organization trail
Storing AWS ALB logs in S3 bucket
Creating CloudWatch Alarms for detecting root login in AWS accounts
Starting OpenSearch and spooling all k8s and app logs to it for prod account
Spinning up Prometheus and Graphana for Prod account for performance monitoring
Installing Karpenter for node scaling

Use the following link to buy the book

https://link.springer.com/book/10.1007/978-1-4842-8673-9

DM me for a 20% Coupon Code on

https://www.linkedin.com/in/rohitsalecha/

https://twitter.com/salecharohit

AWS Inventory Extraction using CloudQuery

Rohit Salecha — Thu, 17 Mar 2022 17:53:01 +0000

Introduction

I wanted to extract the AWS Inventory spread out over multiple regions and accounts. Offcourse there are many solutions and different ways to do this but in this post I'd like to share how I was able to do this using an opensource tool called as CloudQuery

To put in extremely simple words , CloudQuery converts your Cloud(AWS,GCP and many more) asset information into a SQL Database.
For Ex: Below are the columns for the table storing information about your EC2 instances

cq_id,cq_meta,account_id,region,arn,state_transition_reason_time,ami_launch_index,architecture,boot_mode,capacity_reservation_id,cap_reservation_preference,cap_reservation_target_capacity_reservation_id,cap_reservation_target_capacity_reservation_rg_arn,client_token,cpu_options_core_count,cpu_options_threads_per_core,ebs_optimized,ena_support,enclave_options_enabled,hibernation_options_configured,hypervisor,iam_instance_profile_arn,iam_instance_profile_id,image_id,id,instance_lifecycle,instance_type,kernel_id,key_name,launch_time,licenses,metadata_options_http_endpoint,metadata_options_http_protocol_ipv6,metadata_options_http_put_response_hop_limit,metadata_options_http_tokens,metadata_options_state,monitoring_state,outpost_arn,placement_affinity,placement_availability_zone,placement_group_name,placement_host_id,placement_host_resource_group_arn,placement_partition_number,placement_spread_domain,placement_tenancy,platform,private_dns_name,private_ip_address,public_dns_name,public_ip_address,ramdisk_id,root_device_name,root_device_type,source_dest_check,spot_instance_request_id,sriov_net_support,state_code,state_name,state_reason_code,state_reason_message,state_transition_reason,subnet_id,tags,virtualization_type,vpc_id

With the power of SQL, possibilities of utilising this data is endless as an example, if you'd like to identify which EC2 instances are still using IMDSv1 then simply fire the query as

select * from aws_ec2_instances where metadata_options_http_tokens = 'optional' ;

Pre-Requisites

A PostgreSQL database. Below command can be used to quickly spin one up using docker.

docker run --name cloudquery_postgres -p 5432:5432 -v ${PWD}:/tmp -e POSTGRES_PASSWORD=pass -d postgres

A PostgreSQL Administrator tool that can connect to the PGSQL database that we'll spin up
AWS Access Keys configure in ~/.aws/credentials
CloudQuery

NOTE: We are setting up a test bed here and not a production-grade solution.

Configuration

Configuring CloudQuery is quite straightforward and can be easily followed through this link https://docs.cloudquery.io/docs/getting-started/getting-started-with-aws for AWS.

Once CloudQuery has been initialised we need to edit the config.hcl file which cloudquery will read in order to fetch the details.
A sample config.hcl file is as shown below.

The accounts configured must match the different aws profiles configured in ~/.aws/credentials file.

// Configuration AutoGenerated by CloudQuery CLI
cloudquery {
  plugin_directory = "./cq/providers"
  policy_directory = "./cq/policies"

  provider "aws" {
    version = "latest"
  }

// Ensure the credentials match to that of the docker command provided above.
  connection {
    dsn = "postgres://postgres:pass@localhost:5432/postgres?sslmode=disable"
  }
}

// All Provider Configurations

provider "aws" {
  configuration {
// Configuring the different accounts.
    accounts "dev" {
      local_profile = "example-dev"
    }
    accounts "prod" {
      local_profile = "example-prod"
    }
    accounts "staging" {
      local_profile = "example-staging"
    }
    // Optional. by default assumes all regions
    // regions = ["us-east-1", "us-west-2"]
    // Optional. Enable AWS SDK debug logging.
    aws_debug = false
    // The maximum number of times that a request will be retried for failures. Defaults to 5 retry attempts.
    // max_retries = 5
    // The maximum back off delay between attempts. The backoff delays exponentially with a jitter based on the number of attempts. Defaults to 60 seconds.
    // max_backoff = 30
  }

  // list of resources to fetch
  resources = [
    "accessanalyzer.analyzers",
    "acm.certificates",
    "apigateway.api_keys",
    "apigateway.client_certificates",
    "apigateway.domain_names",
    "apigateway.rest_apis",
    "apigateway.usage_plans",
    "apigateway.vpc_links",
    "apigatewayv2.apis",
    "apigatewayv2.domain_names",
    "apigatewayv2.vpc_links",
    "applicationautoscaling.policies",
    "autoscaling.groups",
    "autoscaling.launch_configurations",
    "aws.regions",
    "cloudfront.cache_policies",
    "cloudfront.distributions",
    "cloudtrail.trails",
    "cloudwatch.alarms",
    "cloudwatchlogs.filters",
    "codebuild.projects",
    "cognito.identity_pools",
    "cognito.user_pools",
    "config.configuration_recorders",
    "config.conformance_packs",
    "dax.clusters",
    "directconnect.connections",
    "directconnect.gateways",
    "directconnect.lags",
    "directconnect.virtual_gateways",
    "directconnect.virtual_interfaces",
    "dms.replication_instances",
    "dynamodb.tables",
    "ec2.byoip_cidrs",
    "ec2.customer_gateways",
    "ec2.ebs_snapshots",
    "ec2.ebs_volumes",
    "ec2.eips",
    "ec2.flow_logs",
    "ec2.images",
    "ec2.instances",
    "ec2.internet_gateways",
    "ec2.nat_gateways",
    "ec2.network_acls",
    "ec2.regional_config",
    "ec2.route_tables",
    "ec2.security_groups",
    "ec2.subnets",
    "ec2.transit_gateways",
    "ec2.vpc_endpoints",
    "ec2.vpc_peering_connections",
    "ec2.vpcs",
    "ec2.vpn_gateways",
    "ecr.repositories",
    "ecs.clusters",
    "ecs.task_definitions",
    "efs.filesystems",
    "eks.clusters",
    "elasticbeanstalk.applications",
    "elasticbeanstalk.environments",
    "elasticsearch.domains",
    "elbv1.load_balancers",
    "elbv2.load_balancers",
    "elbv2.target_groups",
    "emr.block_public_access_configs",
    "emr.clusters",
    "fsx.backups",
    "guardduty.detectors",
    "iam.accounts",
    "iam.groups",
    "iam.openid_connect_identity_providers",
    "iam.password_policies",
    "iam.policies",
    "iam.roles",
    "iam.saml_identity_providers",
    "iam.server_certificates",
    "iam.users",
    "iam.virtual_mfa_devices",
    "iot.billing_groups",
    "iot.ca_certificates",
    "iot.certificates",
    "iot.policies",
    "iot.streams",
    "iot.thing_groups",
    "iot.thing_types",
    "iot.things",
    "iot.topic_rules",
    "kms.keys",
    "lambda.functions",
    "lambda.layers",
    "lambda.runtimes",
    "mq.brokers",
    "organizations.accounts",
    "rds.certificates",
    "rds.cluster_parameter_groups",
    "rds.cluster_snapshots",
    "rds.clusters",
    "rds.db_parameter_groups",
    "rds.db_security_groups",
    "rds.db_snapshots",
    "rds.db_subnet_groups",
    "rds.event_subscriptions",
    "rds.instances",
    "redshift.clusters",
    "redshift.subnet_groups",
    "route53.domains",
    "route53.health_checks",
    "route53.hosted_zones",
    "route53.reusable_delegation_sets",
    "route53.traffic_policies",
    "s3.accounts",
    "s3.buckets",
    "sagemaker.endpoint_configurations",
    "sagemaker.models",
    "sagemaker.notebook_instances",
    "sagemaker.training_jobs",
    "secretsmanager.secrets",
    "sns.subscriptions",
    "sns.topics",
    "sqs.queues",
    "ssm.documents",
    "ssm.instances",
    "waf.rule_groups",
    "waf.rules",
    "waf.subscribed_rule_groups",
    "waf.web_acls",
    "wafv2.managed_rule_groups",
    "wafv2.rule_groups",
    "wafv2.web_acls"
  ]
}

// Module Configurations
modules {
  // drift configuration block
  drift "drift-example" {
    // state block defines from where to access the state
    terraform {
      // backend: "local" or "s3"
      backend = "local"

      // local backend options
      // files: list of tfstate files
      files = ["/path/to.tfstate"]

      // s3 backend options
      // bucket   = "<tfstate bucket>"
      // keys     = [ "<tfstate key>" ]
      // region   = "us-east-1"
      // role_arn = ""
    }

    // provider "aws" {
    //   account_ids      = ["123456789"]
    //   check_resources   = ["ec2.instances:*"]
    //   ignore_resources = ["ec2.instances:i-123456789", "aws_cloudwatchlogs_filters:*"]
    // }
  }
}

Once the above stuff is in place fire cloudquery fetch and it'll start populating the SQL database by accessing the AWS inventory from all the accounts that've been configured in the config.hcl file.

Extraction

Once the fetch command completes, open up your favourite PGAdmin console and fire the below SQL Query.

DO
$$
DECLARE 
    r RECORD;
    tbl_name varchar;
    data_exists boolean ;
BEGIN
    FOR r IN SELECT table_name FROM information_schema.tables WHERE table_schema='public'
    LOOP
    tbl_name = r.table_name;
    RAISE NOTICE '%',tbl_name;
    EXECUTE format('select count(*) where exists (select 1 from %s)',tbl_name) INTO data_exists;
    RAISE NOTICE '%',data_exists;
    IF data_exists THEN
       EXECUTE format('COPY %s TO ''%s'' WITH (FORMAT CSV, HEADER)',tbl_name,CONCAT('/tmp/',tbl_name,'.csv'));  
    END IF; 
    END LOOP;
END;
$$;

The Query above iterates through all the tables created by CloudQuery and exports only non-empty
tables in CSV format. The tables aggregate resources from all accounts.

For Ex: if you have 5 S3 buckets , in 3 different accounts , CloudQuery will aggregate all the 5 S3 buckets as 5 rows and a column to desginate the associated account IDs.

End Result would be something like below.

That's all folks hope you find this post useful :-)

Shift Left, Scale Up Security Using Threat Modelling

Rohit Salecha — Mon, 20 Sep 2021 13:01:20 +0000

Security strategies today for most organisations is to

Shift Security left more towards the developers
Engage developers/architects in security processes so as to scale up

Both these points are mutually inclusive i.e. need to be done hand-in-hand. One cannot scaleup security without shifting more towards the left and vice versa. If focus is trained on any one of them then the organisation will end-up in a catch-22 situation.

Addressing the Catch-22

The answer is simple ,Threat Modelling , which is now even recommended in the new OWASP Top 10 - 2021 in the form of A04:2021-Insecure Design.

Currently the new Top 10 is still in the DRAFT stage however, the comunity identifying this as a weakness certainly calls for a change in the way manage security across our organisations.

What is Threat Modelling ?

There are many definitions out there describing threat modelling but in extremely simple terms it is an attempt to identify threats even before the application/feature development starts. Some example threats

A Potential security flaw being exploited
Data leakage
Business continuity being affected
Privilege Escalation
Customer confidence going down and many more ...

One of the best resources that I found is Segment's Threat Modelling Training that they developed internally with an intent to scale up security.

Issues with Adoption of TM

Not many organisations are able to adopt Threat Modelling as a process because

Most of the times Architecture diagrams and other application artefacts like documentation,functional and non-functional requirements are not updated or not captured. Hence contextual information is absent.
In absence of a proper context its difficult to derive threat models
Developers/technical architects are quite averse to using security tools.
Generally a threat modelling tool would spool out quite a lot of threats which overhwhelms the developers leading to friction.

How To ScaleUp + ShiftLeft ?

So how exactly can we scale up and shift left security using Threat Modelling ?

Let's analyse that through the lens of People,Process and Technology, the three pillars of success for any organisation.

People

We'll need two sets of profiles here that are mostly in a mid-senior roles who are an expert in their domain

Technical Architect
- Should have hands-on experience with software development best practices.
- Should be able conceptualise and visualise the architecture of a particular application/product/service alongwith its integrations.
- Should be responsible and accountable for creation and maintenance of the relevant artefacts of a particular application like Architecture Diagrams,Data Flow Diagrams,UMLs,Functional and non-functional requirements,source code etc ...

This is just a very brief of the roles and responsibility of a Technical Architect. Below are some guides for a much more detailed job description

What Does a Technical Architect do - Randstad
Technical Architect Job Description - Workable
- Security Architect
Should be able to enumerate the threats by understanding the application's assets created by the Technical Architects.
Should have a broad understanding of technology components so as to evaluate the risks associated with it. For Ex: most organisations today are migrating to Kubernetes,hence a Security Architect must have some knowledge of how Kubernetes works and how is it being operated not necessary a hands-on,deep dive knowledge.
Provide countermeasures for the identified threats through a medium and context that developers understand.
Security Architect: Job role at a glance - Aarushi Koolwal is a fantastic article describing more about the Security Architect job role.

Technology

In order for the Technical Architect(TA) and Security Architect(SA) to scale up their work they'll need tools.
A tool that can cater to both their requirements.

The interface of the tool should be developer friendly so that she can create architecture diagrams and input application requirements with ease.
Once the requisite information from the TA is received the tool should be able to evaluate the information and generate threats and countermeasures.
Tool must also integrate with whatever ticketting system is being used by the developers to track issues.
The sync between the tool and the ticketting system should also be bi-directional as this will help security architects track issues that've been closed.

Process

The Technical Architect should prepare the relevant application artefacts like app documentation,relevant diagrams , requirements etc ... and add them in the threat modelling tool.
She should be able to present the artefacts to all relevant stakeholders for any new feature/change or a new project altogether by keeping this tool as the point of reference.
Security architects would review the artefacts and the diagrams in the threat modelling tool, remove false +ves and other noise and then add the threats with their countermeasures as a requirement/user story.
Developers can now work on the security requirements alongside other features.

How Would this Help?

With this technique Technical Architects would keep their Architecture Diagrams and other artefacts "Live" and continue to update in the same tool. Hence TA's are now using this tool for their own purpose and not necessarily for security.
Security Architects can keep track of changes and accordingly provide their security requirements by filtering out the noise.

Basically both teams are now working on the same platform and performing their own jobs while at the sametime collaborating with each other ! Hence, we are solving two problems with a single solution.

Image Credit: Microsoft

Bootstrap Security in Kubernetes Deployments

Rohit Salecha — Wed, 11 Aug 2021 09:29:18 +0000

Kubernetes, is one of the most popular and most used container orchestration tool. Kubernetes Workloads are the actual applications that are executed like a simple nginx server or maybe a cron job. Kubernetes Deployments is the most commonly used workload as it can be easily updated,scaled and managed.

The recently released Kubernetes Hardening Guide is an excellent resource that provides a proper guidance on how to effectively secure Kubernetes. The information presented in the guide clearly shows that securing and hardening kubernetes is not just the job of the Kubernetes administrator but also of the developers who are deploying their workload on the clusters.

In this blog I'll discuss about how developers deploying Kubernetes workloads like Deployments can bootstrap security by applying some of the guidelines provided by the 'Kubrnetes Hardening guide'.

This will be a practical hands-on guide where I shall take a simple Dockerfile and then incrementally add the security best practices to create a template Deployment manifest file which can then be reused by developers in a hurry.

Pre-Requisites

Docker is required as we'll be building from ground up.
A single-node Kubernetes cluster like minikube should be sufficient to follow along with this guide alongwith the kubectl utility. You can use the official minikube documentation to set it up in your environment.

I am using a standalone cluster created by Docker Desktop tied to WSL2 as the backend.

This guide will assume that you have a running cluster which is accessible through the kubectl utility as shown below.

Securing Deployments

Securing the kubernetes workloads can effectively be compartimentalised into 'Buildtime' and 'Runtime' security. In order to run with the examples we'll make use of this simple Spring Boot HelloWorld application and deploy it in Kubernetes with buildtime and runtime security applied.

https://github.com/salecharohit/bootstrapsecurityinkubernetesdeployment

So before starting off let's clone this repository,build the docker container and run the application locally

git clone git@github.com:salecharohit/bootstrapsecurityinkubernetesdeployment.git
cd springbootmaven
docker build . -f Dockerfile.basic -t springbootmaven
docker run --name springboot -d -p 8080:8080 springbootmaven
curl http://localhost:8080

Expected Response:

Hello World From Spring Boot Build Using Maven on Alpine OS!

Build Time Security

Buildtime security focusses more on how the underlying containers can be build with a reduced footprint and are programmed to be executed with least possible privileges.

We'll discuss both these approaches with a problem solution approach

Attack Surface Reduction

When building applications in a container the primary objective is to have the app run consistently and indepdently regardless of the environment be it a data center,cloud or even onpremise.
However, when building these apps there is one unwritten rule that it should be a standalone application without much dependencies.

Let's take example of our SpringBoot application. The only dependency for our application to run is that it needs a JVM or Java runtime. Anything else baked into the container is practically useless.

As an example, in our SpringBoot container , which is build on Alpine OS , we don't have any specific need to have the requirement for the apk package manager to be installed.

docker exec -it springboot /bin/sh
apk add curl

So let's try to remove the apk binary and rebuild or docker image.

We'll make use of the Dockerfile.asr at this time to rebuild our docker container which is shared below

FROM maven:3.8.1-openjdk-17-slim AS MAVEN_BUILD
WORKDIR /build/
COPY pom.xml /build/
COPY src /build/src/
RUN mvn package

FROM openjdk:17-alpine

RUN rm -f /sbin/apk && \
    rm -rf /etc/apk && \
    rm -rf /lib/apk && \
    rm -rf /usr/share/apk && \
    rm -rf rm -rf /var/lib/apk

COPY --from=MAVEN_BUILD /build/target/springbootmaven.jar /springbootmaven.jar
EXPOSE 8080
CMD java -jar /springbootmaven.jar

Lets rebuild and re-rerun

# First let's stop the previously running container
docker stop springboot

# Next let's re-build and re-run
docker build . -f Dockerfile.asr -t springbootmaven
docker run --name springboot -p 8080:8080 springbootmaven
docker run --name springboot -d -p 8080:8080 springbootmaven
curl http://localhost:8080

Now let's try to run the apk add curl command again

docker exec -it springboot /bin/sh
apk add curl

So we successfully got rid of the apk dependency and yet have our application running successfully !

Below are some good scripts that've been written specifically for hardenning Alpine OS. Pick and choose depending on your programming language and harden your base alpine image accordingly.

On the Flip-side you can also have a look at the distroless container created by google which is also very highly recommended.

https://github.com/GoogleContainerTools/distroless/tree/main/examples

Switching User Context

One might argue that if an attacker gains an RCE inside the container she might not be able to install packages like curl,wget etc ... to establish her persistence.

However, we are still running as "root" user and technically it is still possible to install apk back

Lets re-run our docker container and check the privileges with which it is currently running.

docker exec -it springboot /bin/sh
whoami
ping rohitsalecha.com

Hence, it is important that we run our container not as root but as a user with limited privileges.

Dockerfile.lpr shows addition of a few more commands that add a user and group called "boot" and assign it a working directory (Which is its home directory)
I've also assigned numerical values to the user and group which we'll discuss in detail in the }}">Pod Security Context Section

FROM maven:3.8.1-openjdk-17-slim AS MAVEN_BUILD
WORKDIR /build/
COPY pom.xml /build/
COPY src /build/src/
RUN mvn package

FROM openjdk:17-alpine

# Removing apk package manager
RUN rm -f /sbin/apk && \
    rm -rf /etc/apk && \
    rm -rf /lib/apk && \
    rm -rf /usr/share/apk && \
    rm -rf rm -rf /var/lib/apk

# Adding a user and group called "boot"
RUN addgroup boot -g 1337 && \ 
    adduser -D -h /home/boot -u 1337 -s /bin/ash boot -G boot

# Changing the context that shall run the below commands with User "boot" instead of root
USER boot
WORKDIR /home/boot

# By default even in a non-root context, Docker copies the file as root. Hence its best practice to chown
# the files being copied as the user. https://stackoverflow.com/a/44766666/1679541
COPY --chown=boot:boot --from=MAVEN_BUILD /build/target/springbootmaven.jar /home/boot/springbootmaven.jar
EXPOSE 8080
CMD java -jar /home/boot/springbootmaven.jar

Lets rebuild and re-rerun

# First let's stop the previously running container
docker stop springboot

# Next let's re-build and re-run
docker build . -f Dockerfile.lpr -t springbootmaven
docker run --name springboot -d -p 8080:8080 springbootmaven
curl http://localhost:8080

Now let's try to run the whoami command and check whats the privileges with which the container is now running

docker exec -it springboot /bin/sh
whoami
ping rohitsalecha.com

Runtime Security

Now that we've got a good level of confidence in the build-time security wherein we've learnt to remove the packages and also update the user context to run the container with limited privileges.
These security features are applied when we are building the docker container however we also need to focus on the security posture of the container when it is running in the Kubernetes environment which we'll explore below.

Before we start of with securing our Kubrnetes deployment let's run our application on our Kubernetes cluster by first pushing our docker container to hub.docker.com. You can use this guide to get started for the same

docker build . -f Dockerfile.lpr -t springbootmaven
docker tag springbootmaven salecharohit/springbootmaven
docker push salecharohit/springbootmaven
docker run -d -p 8080:8080 --name springboot salecharohit/springbootmaven
curl http://localhost:8080

Now that our docker image is ready let's apply our kubernetes-basic.yaml file that will deploy this application and also a service that will help us connect to it.

# Create Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: boot
---
# Create SpringBoot Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springbootmaven
  template:
    metadata:
      labels:
        app: springbootmaven
    spec:
      containers:
      - image: salecharohit/springbootmaven
        name: springbootmaven
        ports:
        - containerPort: 8080
---
# Create Service for SpringBoot Deployment
apiVersion: v1
kind: Service
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  ports:
  - name: "http"
    port: 8080
    targetPort: 8080
  selector:
    app: springbootmaven

Next let's deploy our Kubernetes manifests using the below commands

kubectl apply -f kubernetes-basic.yaml
kubectl get deploy -n boot
# Run a temporary container that will only curl our bootservice
kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080

Expected Output:
Hello World From Spring Boot Build Using Maven on Alpine OS!pod "testpod" deleted

Service Account Tokens

If a Pod needs to communicate with the Kubernetes API-Server it needs Service Account Tokens for authentication.

By default every pod gets assigned a service account token which is mounted on /var/run/secrets/kubernetes.io/serviceaccount/token.
Lets view this in practice by deploying our SpringBoot app

kubectl get pods -n boot
kubectl exec -it springbootmaven-7d7c5c8597-mndv9 -n boot -- /bin/sh
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
curl -k -H "Authorization:Bearer $TOKEN" https://kubernetes.docker.internal:6443/version

An RCE vulnerability on your application can leak this access token to the attacker which she can abuse to read-write resources in the same namespace or even have a global read permissions.

The resolution for this issue is two-fold depending upon the situation.

Pods donot need any access to the API-Server
Pods need access to the API-Server

Pods that donot need access to the API-Server

This situation is farily simple to solve by simply adding two lines to the kubernetes manifest file as shown below

      serviceAccountName: ""
      automountServiceAccountToken: false

The complete deployment file kubernetes-nosa.yaml is as follows

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springbootmaven
  template:
    metadata:
      labels:
        app: springbootmaven
    spec:
      containers:
      - image: salecharohit/springbootmaven
        name: springbootmaven
        ports:
        - containerPort: 8080
      serviceAccountName: ""
      automountServiceAccountToken: false

Let's check if the service account token is now mounted or not

# Ensure our previous deploy is deleted. 
kubectl delete ns boot

# Apply with no service account token
kubectl apply -f kubernetes-nosa.yaml
kubectl get pods -n boot
kubectl exec -it springbootmaven-5568b9874f-8nml8 -n boot -- /bin/sh
cat /var/run/secrets/kubernetes.io/serviceaccount/token

As can be seen from the image the default service account token is no longer mounted.

Pods that need access to the API-Server

In this situation we need to create a ServiceAccount,Role and RoleBinding that maps the ServiceAccount to the Role.
The below Kubernetes manifest

Creates a ServiceAccount called bootserviceaccount to a specific namepspace i.e. boot
Creates a Role called bootservicerole with only privileges to view running pods
Creates a RoleBinding called bootservicerolebinding
Mount the ServiceAccount thus created using the following lines in the Deployment

    ---
          spec:
      containers:
      - image: salecharohit/springbootmaven
        name: springbootmaven
        ports:
        - containerPort: 8080
      serviceAccountName: bootserviceaccount
    ---

This shall allow to only read pods in the "boot" namespace.

The complete deployment file kubernetes-withsa.yaml is as follows

# Create Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: boot
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bootserviceaccount
  namespace: boot
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bootservicerole
  namespace: boot
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bootservicerolebinding
  namespace: boot
subjects:
  - kind: ServiceAccount
    name: bootserviceaccount
    namespace: boot
roleRef:
  kind: Role
  name: bootservicerole
  apiGroup: rbac.authorization.k8s.io
---
# Create SpringBoot Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springbootmaven
  template:
    metadata:
      labels:
        app: springbootmaven
    spec:
      containers:
      - image: salecharohit/springbootmaven
        name: springbootmaven
        ports:
        - containerPort: 8080
      serviceAccountName: bootserviceaccount
---
# Create Service for SpringBoot Deployment
apiVersion: v1
kind: Service
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  ports:
  - name: "http"
    port: 8080
    targetPort: 8080
  selector:
    app: springbootmaven

Let's apply and check if our application is running fine

# Ensure our previous deploy is deleted. 
kubectl delete ns boot

kubectl apply -f kubernetes-withsa.yaml
kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080

Pod Security Contexts

Though we've configured our base docker image to run with non-root privileges however, there are still few more configurations that need to be added as security best practices. These are

Restricting the capabilities of the container and the pod
Disabling Privilege Escalation
Configuring the container to run with a specific uid/gid created earlier in our Dockerfile.lpr

In the kubernetes manifest files there are two types of "SecurityContexts" defined.

Running at Pod-Level which will be applied to all containers running in this pod

      ---
      securityContext:
        fsGroup: 1337
        runAsNonRoot: true
        runAsUser: 1337
      containers:
      ---

Running at Container-level

      ---
        securityContext:
          allowPrivilegeEscalation: false
          privileged: false
          runAsUser: 1337
          capabilities:
            drop: ["SETUID", "SETGID"]
      serviceAccountName: ""
      automountServiceAccountToken: false
      ---

The complete deployment file kubernetes-ps.yaml embedded with the PodSecurity contexts is below

# Create Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: boot
---
# Create SpringBoot Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springbootmaven
  template:
    metadata:
      labels:
        app: springbootmaven
    spec:
      securityContext:
        fsGroup: 1337
        runAsNonRoot: true
        runAsUser: 1337
      containers:
      - image: salecharohit/springbootmaven
        name: springbootmaven
        ports:
        - containerPort: 8080
        securityContext:
          allowPrivilegeEscalation: false
          privileged: false
          runAsUser: 1337
          capabilities:
            drop: ["SETUID", "SETGID"]
      serviceAccountName: ""
      automountServiceAccountToken: false
---
# Create Service for SpringBoot Deployment
apiVersion: v1
kind: Service
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  ports:
  - name: "http"
    port: 8080
    targetPort: 8080
  selector:
    app: springbootmaven

Let's apply and test if our application is running

# Ensure our previous apply is deleted
kubectl delete ns boot
kubectl apply -f kubernetes-ps.yaml
kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080
kubectl get pods -n boot
kubectl exec -it springbootmaven-56c64ff85-mqz2z -n boot -- /bin/sh
whoami
id
ping google.com

You can drop more capabilities as per your requirements. The complete list of capabilities can be found here

https://github.com/torvalds/linux/blob/master/include/uapi/linux/capability.h

Features like AppArmor,SecComp etc ... require additional configurations of the control plane components and hence I've limited my discussion to out-of-the-box features that can be easily activated and ensure good level of security assurance.

Immutable File-Systems

Applications running in a containerised environment seldom write data as it practically goes against the logic of having an immutable system. However, at times it maybe needed for caching or temporary swapping/processing of files. Hence, to provide this functionality to the developer we can mount an emptyDir as an ephemeral volume which is lost once the container is killed.

With this in place we can also add another security context attribute called "readOnlyRootFilesystem" and set it as true since the application running inside the container no longer needs to write anywhere on the file-system other than the 'tmp' directory.

The above requirements can be configured as shown below.

  ---
      containers:
      - image: salecharohit/springbootmaven
        name: springbootmaven
        ports:
        - containerPort: 8080
        securityContext:
          readOnlyRootFilesystem: true
        volumeMounts:
        - mountPath: /tmp
          name: tmp
      volumes:
      - emptyDir: {}
        name: tmp
  ---

The complete deployment file kubernetes-rofs.yaml is as follows

# Create Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: boot
---
# Create SpringBoot Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  replicas: 1
  selector:
    matchLabels:
      app: springbootmaven
  template:
    metadata:
      labels:
        app: springbootmaven
    spec:
      securityContext:
        fsGroup: 1337
        runAsNonRoot: true
        runAsUser: 1337
      containers:
      - image: salecharohit/springbootmaven
        name: springbootmaven
        ports:
        - containerPort: 8080
        securityContext:
          allowPrivilegeEscalation: false
          readOnlyRootFilesystem: true
          privileged: false
          runAsUser: 1337
          capabilities:
            drop: ["SETUID", "SETGID"]
        volumeMounts:
        - mountPath: /tmp
          name: tmp
      serviceAccountName: ""
      automountServiceAccountToken: false
      volumes:
      - emptyDir: {}
        name: tmp

---
# Create Service for SpringBoot Deployment
apiVersion: v1
kind: Service
metadata:
  labels:
    app: springbootmaven
  name: springbootmaven
  namespace: boot
spec:
  ports:
  - name: "http"
    port: 8080
    targetPort: 8080
  selector:
    app: springbootmaven

Let's apply and test if our application is running

# Ensure our previous apply is deleted
kubectl delete ns boot

kubectl apply -f kubernetes-rofs.yaml
kubectl run -it testpod --image=radial/busyboxplus:curl --restart=Never --rm -- curl http://springbootmaven.boot.svc.cluster.local:8080
kubectl get pods -n boot
kubectl exec -it springbootmaven-56c64ff85-mqz2z -n boot -- /bin/sh
pwd
touch test.txt

Conclusion

We've learnt what are the different controls we can embed in our containerised application and also looked at how to enable run-time protection mechanisms that can atleast make things difficult for an external attacker to gain foothold into our containerised systems.

The kubernetes-rofs.yaml can serve as a good template for developers to containerise their applications with default security features enabled while deploying in a Kubernetes environment.

Offcourse the Dockerfile needs to be created for the specific applications but for that purpose I've collected a few of them here

https://github.com/salecharohit/dockerfilesrepo

Reposted From : https://www.rohitsalecha.com/post/bootstrap_security_in_kubernetes_deployments/

References

https://blog.atomist.com/security-of-docker-kubernetes/

-https://media.defense.gov/2021/Aug/03/2002820425/-1/-1/1/CTR_KUBERNETES%20HARDENING%20GUIDANCE.PDF