# AWS S3 Bucket

## Overview

The AWS S3 bucket is used to configure logos and global configuration files in the Complaints Management. 

## Steps

{% stepper %}
{% step %}

### Configure AWS S3 Bucket

The UI assets, like logos and global config files, are hosted in an S3 bucket.

* **Create a new S3 bucket**
* **Add this Bucket Policy** to make the contents public:

```json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicReadGetObject",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::works-dev-asset/*"
        }
    ]
}
```

* Add the below CORS configuration:

```json
[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "GET",
            "PUT",
            "POST",
            "DELETE"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": [
            "x-amz-server-side-encryption",
            "x-amz-request-id",
            "x-amz-id-2"
        ],
        "MaxAgeSeconds": 3000
    }
]
```

{% endstep %}

{% step %}

### Link S3 Bucket in Your Environment Config

To access assets from the S3 bucket in your deployment environment:

* Update  `environment.yaml` file

```
 configmaps:
    egov-config:
      data:
        s3-assets-bucket: "(pg-egov-assets|egov-playground-assets|egov-uat-assets)"
```

* Possible values: `pg-egov-assets`, `egov-playground-assets`, `egov-uat-assets`, etc.
* Restart the **s3-proxy build** after making these changes.

<div><figure><img src="https://805553164-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FszvWp0bRxYU0P0l6DKOo%2Fuploads%2FmZ9uxwpAfPL5zAvSS79Y%2FScreenshot%202025-07-15%20at%209.55.37%E2%80%AFAM.png?alt=media&#x26;token=2bdec9fc-b979-4c44-8b45-6100f8b41f2b" alt=""><figcaption></figcaption></figure> <figure><img src="https://805553164-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FszvWp0bRxYU0P0l6DKOo%2Fuploads%2F9OkjCd9Da3a9E6UosYT7%2FScreenshot%202025-07-15%20at%209.55.26%E2%80%AFAM.png?alt=media&#x26;token=a19cda7c-ef22-4146-a065-ec25b28d303e" alt=""><figcaption></figcaption></figure></div>
{% endstep %}
{% endstepper %}

### **Other viable options in the CMS context**

1. **Azure Blob Storage**
   * Works similarly to S3.
   * Can be configured with public access or via signed URLs.
   * Would require updating the `s3-proxy` or using an Azure CDN endpoint in the environment configuration.
2. **Google Cloud Storage (GCS)**
   * Also supports static asset hosting.
   * Public bucket policy or signed URLs are possible.
   * Integration changes needed in the configmaps.
3. **Self-hosted HTTP/HTTPS static server**
   * Assets are placed in an Nginx/Apache/static-file server inside your infra.
   * No cloud dependency, but you need to manage uptime, scaling, and cache headers.
4. **GitHub Pages or similar static site hosting**
   * For purely static assets (logos, configs), you can use GitHub Pages, Netlify, or Vercel.
   * Would require adjusting the asset URLs in `environment.yaml`.
5. **Kubernetes ConfigMaps or PVC (Persistent Volume Claim)**
   * Small static files can be mounted directly from ConfigMaps.
   * Good for a few KBs of data, but not ideal for large or frequently updated assets.

***

#### **Key consideration in CMS**

If you replace AWS S3:

* You must ensure **public accessibility** or proper authentication.
* Update `s3-assets-bucket` (or equivalent) in `environment.yaml` to point to the new hosting location.
* If using `s3-proxy` it may need to be replaced with a generic proxy or direct asset URL.