# Ensure Redshift cluster is encrypted in transit

- Source: https://support.icompaas.com/support/solutions/articles/a_1793292246584693-ensure-redshift-cluster-is-encrypted-in-transit
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [AWS_Checks_v5.39.1](https://support.icompaas.com/support/solutions/c_1793285913477877) › [AWS Checks](https://support.icompaas.com/support/solutions/folders/f_1793287194371224)
- Last updated: 2026-10-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

**Description**

Ensure that every Amazon Redshift provisioned cluster requires TLS (SSL) for client connections. This is controlled by the require\_ssl parameter in the parameter group associated with the cluster, which must be set to true.

**Rationale**

If TLS is optional, client sessions can use plaintext connections, allowing credentials, queries and results to be intercepted or modified in transit, and sessions to be hijacked. Setting require\_ssl to true makes the cluster reject connections that do not use TLS. Clients should also validate the server certificate, use current drivers and connect over private network paths where possible.

**Impact**

-   Protects credentials, queries and query results in transit
    
-   Clients or tools that connect without SSL will be rejected and must be configured to use SSL before the change
    
-   The cluster must be rebooted for the parameter change to take effect, which causes a short outage
    

**Default Value**

The default parameter group of a cluster cannot be modified. Whether require\_ssl is true in it depends on when the cluster was created: newer clusters require SSL by default, while older clusters may still allow unencrypted connections.

**Pre-Requisites**

-   IAM permissions: redshift:DescribeClusters, redshift:DescribeClusterParameters, redshift:CreateClusterParameterGroup, redshift:ModifyClusterParameterGroup, redshift:ModifyCluster and redshift:RebootCluster
    
-   Confirmation that all clients, BI tools and ETL jobs connect with SSL enabled
    
-   A maintenance window for the cluster reboot
    

**Remediation**

**Test Plan**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon Redshift console and select **Clusters**.
    
3.  Select each cluster, open the **Properties** tab and note the parameter group in **Database configurations**.
    
4.  Open that parameter group and check that require\_ssl is set to true.
    
5.  Repeat for each region in use.
    
6.  If require\_ssl is false for any cluster's parameter group, follow the implementation steps.
    

**CLI:**

Show the parameter group of each cluster:

aws redshift describe-clusters --region <REGION> --query "Clusters\[\].\[ClusterIdentifier,ClusterParameterGroups\[0\].ParameterGroupName\]" --output table

Show the require\_ssl value of a parameter group:

aws redshift describe-cluster-parameters --region <REGION> --parameter-group-name <PARAMETER\_GROUP\_NAME> --query "Parameters\[?ParameterName=='require\_ssl'\].\[ParameterName,ParameterValue\]" --output table

A cluster fails if require\_ssl is not true in its parameter group.

**Implementation Steps**

**Console:**

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon Redshift console and go to the parameter groups page (under **Configurations**, **Workload management**).
    
3.  If the cluster uses a default parameter group, choose **Create** and create a custom parameter group.
    
4.  Open the custom parameter group, choose **Edit parameters**, set require\_ssl to true and choose **Save**.
    
5.  If a new parameter group was created, select the cluster under **Clusters**, open the **Properties** tab, edit **Database configurations** and select the new parameter group.
    
6.  Reboot the cluster (**Actions**, then **Reboot**) to apply the change.
    
7.  Repeat for each affected cluster in each region in use.
    

**CLI:**

The command below fails on a default parameter group, which cannot be modified, so a custom parameter group is created first when needed.

Create a custom parameter group (only if the cluster uses a default one). Use the same family as the cluster's current parameter group, for example redshift-1.0 or redshift-2.0:

aws redshift create-cluster-parameter-group --region <REGION> --parameter-group-name <PARAMETER\_GROUP\_NAME> --parameter-group-family <PARAMETER\_GROUP\_FAMILY> --description "Require SSL"

Set require\_ssl to true in the parameter group:

aws redshift modify-cluster-parameter-group --region <REGION> --parameter-group-name <PARAMETER\_GROUP\_NAME> --parameters ParameterName=require\_ssl,ParameterValue=true

Associate the parameter group with the cluster (only if it was newly created):

aws redshift modify-cluster --region <REGION> --cluster-identifier <CLUSTER\_ID> --cluster-parameter-group-name <PARAMETER\_GROUP\_NAME>

Reboot the cluster to apply the change:

aws redshift reboot-cluster --region <REGION> --cluster-identifier <CLUSTER\_ID>

**Backout Plan**

Before making changes, save the current parameter values:

aws redshift describe-cluster-parameters --region <REGION> --parameter-group-name <PARAMETER\_GROUP\_NAME> > redshift-parameters-backup.json

To roll back:

1.  Sign in to the AWS Management Console at [https://console.aws.amazon.com](https://console.aws.amazon.com/).
    
2.  Open the Amazon Redshift console and open the parameter group used by the cluster.
    
3.  Choose **Edit parameters**, set require\_ssl back to false and choose **Save**, or associate the cluster with its previous parameter group.
    
4.  Reboot the cluster to apply the change.
    

**CLI:**

aws redshift modify-cluster-parameter-group --region <REGION> --parameter-group-name <PARAMETER\_GROUP\_NAME> --parameters ParameterName=require\_ssl,ParameterValue=false

Note: rolling back allows unencrypted client connections again. Use it only as a temporary measure while clients are updated.

**Reference**

-   [https://docs.aws.amazon.com/redshift/latest/mgmt/security-encryption-in-transit.html](https://docs.aws.amazon.com/redshift/latest/mgmt/security-encryption-in-transit.html)
    
-   [https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html)
    
-   [https://docs.aws.amazon.com/securityhub/latest/userguide/redshift-controls.html#redshift-2](https://docs.aws.amazon.com/securityhub/latest/userguide/redshift-controls.html#redshift-2)
    
-   [https://docs.aws.amazon.com/cli/latest/reference/redshift/modify-cluster-parameter-group.html](https://docs.aws.amazon.com/cli/latest/reference/redshift/modify-cluster-parameter-group.html)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.
