S3 Bucket Policies

-

In this blog, I will walk you through with some of the interesting S3 bucket polices to secure the bucket and objects.

I have a bucket called “demo-aws-sathiya”. 

 

I need the bucket to be accessed from other regions and from outside AWS (On Prem).

Hence, I created a S3 VPC Interface Endpoint.


To access S3 bucket via VPCE interface endpoint we need to use the DNS name of the S3 VPC Interface Endpoint.

By default, the S3 VPCE policy allows access to all the buckets in that account.


Let’s start by implementing a policy at the S3 VPC Interface Endpoint level to restrict access to all buckets except the required ones.



This allows access to the bucket "demo-aws-sathiya" to be accessed using the S3 VPC interface endpoint.

I get access denied when I try to access others bucket NOT ALLOWED in the policy.


Next, our bucket has empty bucket policy which means it is accessible from outside. 

Now, we need to make sure the bucket is accessed only via S3 VPC Interface endpoint.

Hence, I am updating the bucket policy.

Lets test it and it is accessible.

I get access denied when I try to access the same bucket without using S3 VPC interface endpoint.


Lets add one more layer to disable HTTP access via S3 interface endpoint to the bucket.


aws:SecureTransport is an AWS global condition key used in S3 bucket policies to deny any request made over HTTP and allow only HTTPS.

Next, Lets update the bucket policy to ensure all the object actions are done using the "AuthType" as "REST-HEADER" -> Request is authenticated using the "Authorization" header (CLI or Programmatic mode)



Finally, lets enforce the object upload to the bucket must specify the encryption type as "AES256".


We are mandating the upload object using SSE-S3 - AES256.

I created a file and uploaded and ended up with ACCESS DENIED.



Lets try the same with -sse flag as AES256 and it worked.




Comments

Post a Comment

Popular posts from this blog

K8s - ETCD

-
Image
  etcd is a "strongly consistent , distributed key-value store". Why etcd? 1. Consistency : Since the API server is the central coordination point of the entire cluster; strong consistency is essential. It would be a disaster if, say, two nodes tried to attach the same persistent volume over iSCSI because the API server told them both that it was available. 2. Availability: API downtime means that the entire Kubernetes control plane comes to a halt, which is undesirable for production clusters. The  CAP theorem  says that 100% availability is impossible with strong consistency, but minimizing downtime is still a critical goal. 3. Consistent Performance: The API server for a busy Kubernetes cluster receives a fair amount of read and write traffic. The secret behind etcd's balance of strong consistency and high availability is the  Raft algorithm . Raft solves a particular problem: how can multiple independent processes decide on a single value for somethin...
Read more

K8s - Deployment and HPA replicas

-
Image
  We all know that replica is a critical part of a K8s deployment. Default replica is 1. Setting replicas as 3 will ensure 3 pods of that deployment is running at any given time.  Replica are internally managed by replica set which is in turn controlled by the K8s  ReplicationController   . When a pod is bad or deleted as part of replicaset, replication controller will ensure a new pod is created. Now, coming to HPA (Horizontal Pod Autoscaler) which is a dynamic scaler which works at the pod level based on the metrics configured.  When we configure we must mention min and max values. They should be greater than 1. Let's image I create a HPA with min as 5 and max as 10 under the condition of CPU utilization more than 50%. Initial deployment is set with the replica as 1. On top the deployment, I am attaching a HPA with the mentioned configuration. Under HPA, we are forcing the min replicas to 5. Hence, it autoscales the pod to 5 even though the CPU utilization is ...
Read more

K8s - User and Groups

-
Image
  In this post, we will see how user and group works. Technically, there is no concept of user and group management in K8s.  But, K8s has something called "Service Account" . When K8s is installed from scratch, every namespace has "default" service account and it has admin access to perform actions. It is not practically possible to use " default " service account for every actions. From security point of view, we need to give fine grained and required access.  K8s has 2 important things in the space of "Access Management". Role and RoleBinding [Namespace Scoped] Role : Create a role with actions allowed actions on the resources. Let's say I want to create a readonly role. Using the role users can only view the resource and cannot perform actions like create, modify, delete. Rolebinding : Attaching the role to a user, group and service account is called "Role Binding". apiVersion : rbac.authorization.k8s.io/v1 kind : Role metadata :...
Read more