Cloudfront With Squiz Edge being an origin

Just wanted to share an insight on trying to do an Squiz CMS overlay beside another product that has no CMS features. I.E a homepage of a COTS solutions.


Problem space:
I want to have the squiz edge as an origin in cloudfront so that i can have some pages fully managed by the content team without developer intervention.

Issues encounted
cloudfront started returning 502 errors which their documentation relates to ssl issues.
Squiz the company needs to be contacted to do an update on their squiz edge system to acknowledge your hostname as well as setup required inside squiz matrix.

Outcome:

Cloudfront has two rules for SSL passthrough,

Rule 1: Origin Domain Name you request against must  match ssl cert

Rule 2: If Rule1 fails, Host header must match ssl cert.

If my front end domain is zyx.

My Origin Domain Name is lpo

If the origin returns ssl cert zyx or lpo it will pass. If it passes abc it will fail.

Now in relation to Squiz.

When we do a low level ssl cert check against their staging edge network if the server name is the hostname, we get *.squizedge.net

If its (valid configured domain without custom ssl cert) we get *.clients.net.au if its (invalid domain) we get *.squizedge.net

What we want is to have *.squizedge.net to be provided to as instead of *.clients.squiz.net cert. 

Below is how to test.

openssl s_client -showcerts -servername staging.squizedge.net -connect staging.squizedge.net:443
depth=0 C = AU, ST = New South Wales, L = Sydney, O = SQUIZ PTY LTD, CN = *.squizedge.net

openssl s_client -showcerts -servername (valid domain without custom ssl cert) -connect staging.squizedge.net:443

depth=0 C = AU, ST = New South Wales, L = Sydney, O = Squiz Australia Pty. Ltd., CN = *.clients.squiz.net

openssl s_client -showcerts -servername (invalid domain) -connect staging.squizedge.net:443

depth=0 C = AU, ST = New South Wales, L = Sydney, O = SQUIZ PTY LTD, CN = *.squizedge.net

openssl s_client -showcerts -servername (valid domain with custom ssl cert) -connect staging.squizedge.net:443

(valid ssl cert depth=0 provided)

ALSO 

do ensure you are picking tls1.1 or higher as ssl3 handshake with squizedge is an instant deny

 openssl s_client -showcerts -connect staging.squizedge.net:443 -servername (valid domain without custom ssl cert)  -ssl3
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : SSLv3
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1564975196
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
---

AWS: Why does Auto Minor Version Upgrade Flag not upgrade to latest minor Version of Database.

Shout out to Asmita V. for this answer.

------------------------------------------
PROBLEM DESCRIPTION
------------------------------------------

Why were the RDS PostgreSQL instances not automatically upgraded to the latest Minor Version available even though the Auto Minor Version Upgrade Flag is enabled for your instances.

------------------------------------------
RESPONSE
------------------------------------------

The reason why your instances was not upgraded to these minor version is that AMVU will only upgrade the engine version for your RDS instance if the current engine version is being deprecated or the new one contains very important cumulative bug fixes and an upgrade is absolutely necessary. 

Please note that while we highly recommend that you perform an upgrade to 10.9, this upgrade will not happen automatically as of now using AMVU as the automatic upgrades happen only when absolutely necessary and you can also view such actions using describe-pending-maintenance-actions command.

If there is an auto minor version upgrade scheduled as a maintenance, please be assured that you will get a separate notification explicitly mentioning the same. Currently, in this case the upgrade will have to be applied manually.

Further, at your end, you can check if the minor version upgrade will happen automatically or not by using the below CLI command:

$aws rds describe-db-engine-versions --output=table --engine postgres --engine-version 10.6

Output:
||+-------------------------------------------------------------------------------------------+||
|||                                    ValidUpgradeTarget                                     |||
||+-------------+---------------------+-----------+----------------+--------------------------+||
||| AutoUpgrade |     Description     |  Engine   | EngineVersion  |  IsMajorVersionUpgrade   |||
||+-------------+---------------------+-----------+----------------+--------------------------+||
|||  False      |  PostgreSQL 10.7-R1 |  postgres |  10.7          |  False                   |||
|||  False      |  PostgreSQL 10.9-R1 |  postgres |  10.9          |  False                   |||
|||  False      |  PostgreSQL 11.1-R1 |  postgres |  11.1          |  True                    |||
|||  False      |  PostgreSQL 11.2-R1 |  postgres |  11.2          |  True                    |||
|||  False      |  PostgreSQL 11.4-R1 |  postgres |  11.4          |  True                    |||
||+-------------+---------------------+-----------+----------------+--------------------------+||

As you can see from the above output, for 10.6 version "AutoUpgrade" column is marked as "False" for all minor version upgrade (either 10.7 or 10.9) . So, it has to be done manually. Please make sure to upgrade to the latest minor version  (10.9)  so that you wont be prone to any security vulnerabilities as per the following notice:

[+] https://www.postgresql.org/about/news/1949/

AWS: How should we upgrade PostgreSQL 10.6 to 10.9 version of CloudFormation-controlled RDS instances

Shout out to Asmita V. for this answer.

Upgrade RDS PostgreSQL instances from 10.6 to 10.9 and in this process you want to understand that whether setting the "AllowMajorVersionUpgrades" flag in the CloudFormation template be sufficient and if during the process, existing instances will get replaced.

------------------------------------------
RESPONSE
------------------------------------------

Upgrading the PostgreSQL instance from version 10.6 to 10.9 is a minor version upgrade and hence would not require you to change the value of the parameter "AllowMajorVersionUpgrades" in your cloudformation template.

In order to upgrade your instances from 10.6 to 10.9 you can make a modification in your CFN stack by just specifying the "Engine Version" as 10.9 instead of 10.6 in your template. There is no replacement of the existing instance and hence there will be no loss of data. The existing instances will go to a "Modifying" State.

In order to confirm this behavior, I tried upgrading resources in my test environment and following are my observations:

---------------------------------------------
Testing
---------------------------------------------
Please refer the following set of steps that I took in order to upgrade my instance to 10.9 from 10.6:

Sample Stack
============================

{
  "AWSTemplateFormatVersion" : "2010-09-09",
  "Description" : "PostgreSQL RDS Template ",
  "Resources": {
    "pgDB" : {
      "Type" : "AWS::RDS::DBInstance",
      "Properties" : {
        "DBName" : "mydb",
        "DBInstanceClass" : "db.t2.small",
        "AllocatedStorage" : "20",
        "Engine" : "postgres",
        "EngineVersion": "10.6",
        "MasterUsername" : "username",
        "MasterUserPassword" : "password",
        "AutoMinorVersionUpgrade": false
      }
    }
  }
}

Step 1: Make Changes to the existing template
=======================================

1. On the Stacks page of the AWS CloudFormation console, click the name of the stack that you want to update.  https://console.aws.amazon.com/cloudformation
2. Select the Template tab and select View on Designer.
3. Modify the CFN Stack : "EngineVersion": "10.9"
        {
          "AWSTemplateFormatVersion" : "2010-09-09",
          "Description" : "PostgreSQL RDS Template ",
          "Resources": {
            "pgDB" : {
              "Type" : "AWS::RDS::DBInstance",
              "Properties" : {
                "DBName" : "mydb",
                "DBInstanceClass" : "db.t2.small",
                "AllocatedStorage" : "20",
                "Engine" : "postgres",
                "EngineVersion": "10.9",
                "MasterUsername" : "username",
                "MasterUserPassword" : "password",
                "AutoMinorVersionUpgrade": false
              }
            }
          }
        }
4. Validate you template.
5. Select Save. Save your template to S3 bucket.
6. Click on Save and copy the URL.
       
Ex. https://s3-external-1.amazonaws.com/cf-templates-us-east-1/template1
       
Step 2: Create Change Set for Current Stack
=======================================

1. On the Stacks page of the AWS CloudFormation console, click the name of the stack that you want to update.  https://console.aws.amazon.com/cloudformation
2. Go to Stack Actions and select "Create change set for current stack".
3. Select "Replace current template"
4. Input the URL that was copied in the Step 1:6.
5. On the Review page, click on Create Change Set.
6. In the preview page, under the Changes you will notice "Modify" under the Action column.
7. Click on Execute.

You can now check on the RDS Console. The status of the RDS instance would have gone to "Upgrading".

However, please note that engine version upgrade (major or minor) is always associated with some amount of downtime.

Even if your DB instance is in a Multi-AZ deployment, both the primary DB instance and standby DB instances are upgraded. The writer and standby DB instances are upgraded at the same time, and you experience an outage until the upgrade is complete.

Therefore it is always recommended to plan your upgrades in the non business hours.

[+] Upgrading the PostgreSQL DB Engine for Amazon RDS - https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html

[+] Modifying a DB Instance Running the PostgreSQL Database Engine  - Settings for PostgreSQL DB Instances - https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ModifyPostgreSQLInstance.html#USER_ModifyInstance.Postgres.Settings

---------------------------------------------
Conclusion
---------------------------------------------
Therefore, as per my testing, I can confirm that there will be no replacement of the existing instance during the process of upgrading PostgreSQL instance from  v10.6 to 10.9.
You may also go ahead and follow the steps given above in order to upgrade your instances.

---------------------------------------------
REFERENCES
---------------------------------------------

[+] Updating Stacks Using Change Sets  - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets.html

[+] Creating a Change Set  - https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-changesets-create.html