Showing posts with label CFN. Show all posts
Showing posts with label CFN. Show all posts

Thursday, February 02, 2023

How to find Private Network Load Balancer (NLB) ALBv2 IP4 addresses for adding to security group to allow health checks to pass

 Use case:

My Target Groups attached to my Load Balancer route to a private internal port that is not on the security group white listing.   Due to Network Load Balancer's use of the EC2 connected Security Group. I don't want to whitelist the private internal port to the internet for possible bypass.

This can be done manually in the aws console by finding the ENI by looking up the ELB (type)/(name)/(random string) getting the private ip4 and then adding them manually to the security group.


But this defeats the purpose of having a cloudformation script that automatically stands up everything to work.

in this example we want to get the private ip4 address of a ELBv2 (network). Full working example: https://github.com/qld-gov-au/quickstart-atlassian-bitbucket/blob/d6ebe59b5ccdd204a7edc72ab6f0f89d575ac6f8/templates/quickstart-bitbucket-dc.template.yaml 



(non-gist version below)

#Network Load Balancer health checks, need internal ip to approve connectivity

InternalNLBIp4List:
  DependsOn: NetworkLoadBalancerELB2
  Type: Custom::InternalNLBIp4ListCollector
  Version: 1.0
  Properties:
    ServiceToken: !GetAtt InternalNLBIp4ListCollector.Arn
    ELBv2Arn: !Ref NetworkLoadBalancerELB2
    StackName: !Ref 'AWS::StackName'
InternalNLBIp4ListCollector:
  Type: "AWS::Lambda::Function"
Properties:
    Handler: index.lambda_handler
    Role: !GetAtt InternalNLBIp4ListCollectorExecutionRole.Arn
    Runtime: python3.7
    Timeout: 120
    Code:
      ZipFile: |
        import cfnresponse
        import boto3

        def lambda_handler(event, context):
          elbv2 = boto3.client('elbv2')
          ec2 = boto3.client('ec2')
          elb2arn = event['ResourceProperties']['ELBv2Arn']
          response = elbv2.describe_load_balancers(LoadBalancerArns=[elb2arn])
          name = response['LoadBalancers'][0]['LoadBalancerName']
          elbtype = response['LoadBalancers'][0]['Type']
          filters = [{'Name': 'description', 'Values': ['ELB '+ elbtype[0:3] + '/' + name + '*']}]
          eni_response = ec2.describe_network_interfaces(Filters=filters)
          ip_addresses = [eni['PrivateIpAddress'] for eni in eni_response['NetworkInterfaces']]
          ip_addresses_cidr = [eni['PrivateIpAddress'] + '/32' for eni in eni_response['NetworkInterfaces']]
          print (ip_addresses)
          responseData = {}
          responseData['PrivateIpAddresses'] = ip_addresses
          responseData['PrivateIpCidrAddresses'] = ip_addresses_cidr
          cfnresponse.send(event, context, cfnresponse.SUCCESS, responseData)

InternalNLBIp4ListCollectorExecutionRole:
  Type: "AWS::IAM::Role"
Properties:
    AssumeRolePolicyDocument:
      Version: '2012-10-17'
Statement:
        - Effect: Allow
          Principal:
            Service:
              - lambda.amazonaws.com
          Action:
            - sts:AssumeRole
    Path: "/"
Policies:
      - PolicyName: root
        PolicyDocument:
          Version: '2012-10-17'
Statement:
            - Effect: Allow
              Action:
                - logs:CreateLogGroup
                - logs:CreateLogStream
                - logs:PutLogEvents
              Resource: !Sub "arn:${AWS::Partition}:logs:*:${AWS::AccountId}:log-group:/aws/lambda/*InternalNLBIp4ListCollector*"
- Effect: Allow
              Action:
                - "elasticloadbalancing:DescribeLoadBalancers"
- "ec2:DescribeNetworkInterfaces"
Resource: "*"
#NLB ip's need to be whitelisted to allow health checks to pass
SecurityGroupIngressNLB:
  DependsOn:
    - InternalNLBIp4List
    - SecurityGroup
  Type: AWS::EC2::SecurityGroupIngress
  Properties:
    GroupId: !Ref SecurityGroup
    IpProtocol: "-1"
FromPort: -1
    ToPort: -1
    CidrIp: !Select [ 0, !GetAtt InternalNLBIp4List.PrivateIpCidrAddresses ]

SecurityGroupIngressNLB2: #ELB in 2 subnets, will have 2 ip's
DependsOn:
    - InternalNLBIp4List
    - SecurityGroup
  Type: AWS::EC2::SecurityGroupIngress
  Properties:
    GroupId: !Ref SecurityGroup
    IpProtocol: "-1"
FromPort: -1
    ToPort: -1
    CidrIp: !Select [ 1, !GetAtt InternalNLBIp4List.PrivateIpCidrAddresses ]

Wednesday, July 17, 2019

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