Securing Elastic IP addresses from accidental release

Have you wondered what are the best practices in safeguarding your infrastructure from unintended release of Elastic IP addresses? In this blog, we are providing a few proactive self-service solutions to streamline IP handling and obtaining a robust environment for critical applications. Before diving into the solution, let us revisit some key concepts of AWS Public IPv4 addresses.

Customers typically work with two types of public IPv4 addresses; the first type is called an Elastic Compute Cloud Public IPv4 [EC2 Public IPv4] and the second type is called as an Elastic IP, or EIP as commonly referenced. EC2 Public IPv4 addresses are dynamic in nature and are automatically assigned to EC2 instances during launch on a subnet with auto-assign public IPv4 enabled. Such public IPv4 addresses are not tied to your account and will be released back to the AWS pool if you stop, terminate, or hibernate the EC2 instance and are not recoverable. On the other hand, EIPs are allocated to your AWS account upon request. Once allocated, you can then associate and disassociate between AWS resources and they continue to remain in your account until you release them.

EIPs serve as static IPv4 addresses that are leveraged by our customers for critical workloads. Due to their static and persistent nature, they are also used as part of allow lists within firewalls for data security. An accidental release of such EIPs will cause service impacts in addition to the operational burden of re-configuring firewalls. Although you can retrieve the same EIPs, but this action is time sensitive and not guaranteed as an EIP allocated to another account cannot be recovered.

Preserving such Elastic IP addresses is important, so in this blog post we’ll provide step-by-step guidance on how to prevent such events by effectively using custom policies in your environment.

Solution overview

Elastic IP addresses can be released via the AWS console, CLI, or SDK. When any actions are performed, AWS evaluates all policies attached to the users, roles, or user groups also commonly referred as IAM identities to determine if they are authorized.

You can create a policy which serves as a control to choose which users, groups, or roles can release an EIP. You can do this by configuring the permission with Action:“ec2:ReleaseAddress” and its Effect as “Deny” within the policy. As shown in figure 1, having such a policy attached to an identity, when an identity tries to release your EIPs, they will receive a client error: “Unauthorized Operation” thus stopping from executing this action.

                                                                                Figure 1: Solution overview

Depending on your organization structure, you can implement one of the below one-stop solutions to efficiently secure EIP addresses from accidental releases across regions:

1. Using Customer Managed Policy (CMP) that applies to a user, role or group within an account.
2. Using Service control policy (SCP) that applies to multiple accounts across your AWS Organizations.
3. Protecting cluster of critical EIPs by configuring resource level permissions within the policies.

Pre-requisites

• Permission to create, modify, and attach IAM and SCP policies
• Access to AWS Console
• Access to AWS CLI

Additionally, below are some recommendations that you should consider before getting started with this solution:

1. If you are using the solution via CMP, as a security best practice we recommend attaching the policy to IAM roles over a user or group.
2. If you are using the solution via SCP for your organization, we would suggest to go through some of the considerations mentioned in here.
3. AWS strongly recommends that you don’t attach SCPs to the root of your organization without thoroughly testing the impact that the policy has on accounts. Instead, create an Organizational Unit (OU) that you can move your accounts into one at a time, or at least in small numbers, to ensure that you don’t inadvertently lock users out of key services.

Walkthrough

1) Prevent EIP accidental release using customer managed policy [CMP]

CMP is a type of policy managed by you whereby you can allow or deny access to specific user, role, or user group within an account. Please note that if your organization also utilizes SCP (see figure 2), CMP will have to allow the identity to access a resource in addition to the SCP.

Figure 2: Effective permission when CMP and SCP intersect

For the purpose of this blog, the example below walks you through configuring permission to Deny releasing all EIPs and attach the policy to a role.

Create and attach customer managed policy

AWS CLI

Create a CMPPolicy.json file and add the below permission.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Deny",
"Action": "ec2:ReleaseAddress",
"Resource": "*"
}
]
}

aws iam create-policy --policy-name DenyReleaseAddresses --policy-document file://CMPpolicy.json --description "This policy denies releasing EIP addresses"

{
"Policy": {
"PolicyName": "DenyReleaseAddresses",
"PolicyId": "abcdefgh1xyzhe",
"Arn": "arn:aws:iam::<account_Id>:policy/DenyReleaseAddresses",
"Path": "/",
"DefaultVersionId": "v1",
"AttachmentCount": 0,
"PermissionsBoundaryUsageCount": 0,
"IsAttachable": true,
"CreateDate": "2023-xx-xxTxx:xx:xx+00:00",
"UpdateDate": "2023-xx-xxTxx:xx:xx+00:00"
}
}

aws iam attach-role-policy --role-name DEV_testing --policy-arn arn:aws:iam::<account-id>:policy/DenyReleaseAddress

You can also attach policy to other identities such as user or group.

Alternatively, from AWS Console create a customer managed policy that contains above permission as shown in figure 3 and attach the policy to a role as shown in figure 4:

                                                       Figure 3: Create customer managed policy in AWS console

                                                        Figure 4: Attach customer managed policy to IAM role in AWS console

Modify existing customer managed policy

You can also update your existing customer managed policy by adding permission to Deny releasing all EIPs. A policy with Deny would take precedence over any other policies with Allow attached to the identity. Please note, this modification will apply to all the identities that is currently attached to the policy.

AWS CLI

Create a modifyExistingCMP.json file that contains permissions of existing managed policy along with the new permission such as below:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups",
                "logs:CreateLogGroup"
            ],
            "Resource": "*"
        },
        {
            "Sid": "2",
            "Effect": "Deny",
            "Action": "ec2:ReleaseAddress",
            "Resource": "*"
        }
    ]
}

aws iam create-policy-version --policy-arn arn:aws:iam::<account_id>:policy/Defaultvpc --policy-document file://modifyExistingCMP.json --set-as-default

{
    "PolicyVersion": {
        "VersionId": "v2",
        "IsDefaultVersion": true,
        "CreateDate": "2023-xx-xxThh:mm:ss+00:00"
    }
}

Alternatively, from AWS Console edit existing customer managed policy that contains above permission as shown in figure 5 and check to set this new version as the default before saving as shown in figure 6.

                                                       Figure 5: Update existing customer managed policy via AWS console

                                                         Figure 6: Set the modified policy as default to take into effect

2) Prevent EIP accidental release using service control policies (SCP)

SCPs offer central control and ensure accounts within an organization adhere to guidelines. SCPs are similar to AWS Identity and Access Management (IAM) policies and use almost the same syntax. In this blog post, we are configuring SCP to prevent all member accounts within your organization from releasing any EIP Addresses.

Step 1: Enable policy type
You can enable a policy type from only the organization’s management account.

AWS CLI

aws organizations enable-policy-type --root-id r-examplerootid111 --policy-type SERVICE_CONTROL_POLICY

Note: that you must specify the ID of your organization’s root for enabling an SCP but you can attach it to any Organizational Unit (OU).

Alternatively, from AWS Console to enable policy type as shown in figure 7.

                                                                        Figure 7: Enable SCP type policy via AWS console

Step 2: Create and attach SCP policy

AWS CLI

Create a SCPPolicy.json file and add the below permission.

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Deny",
"Action": "ec2:ReleaseAddress",
"Resource": "*"
}
]
}

aws organizations create-policy --content file://SCPpolicy.json  --name DenyReleaseAddress  --type SERVICE_CONTROL_POLICY  --description "This policy prevents accidental release of EIP addresses"

{
    "Policy": {
        "PolicySummary": {
            "Id": "p-abcdefghijk",
            "Arn": "arn:aws:organizations::<acccount_id>:policy/o-aa111bb222/service_control_policy/p-abcdefghijk",
            "Name": "DenyReleaseAddress",
            "Description": "This policy prevents accidental release of EIP addresses",
            "Type": "SERVICE_CONTROL_POLICY",
            "AwsManaged": false
        },
         "Content": "{\"Version\":\"2012-10-17\",\"Statement\":[{\"Sid\":\"Statement1\",\"Effect\":\"Deny\",\"Action\":[\"iam:*\"],\"Resource\":[\"*\"]}]}"
    }
}

aws organizations attach-policy --policy-id p-abcdefghijk --target-id ou-a1b2-cccc3333

Alternatively, from AWS console create a policy as shown in figure 8 and attach the policy as show in figure 9.

                                                                       Figure 8: Create SCP policy via AWS Console

                                                                      Figure 9: Attach SCP policy via AWS Console

3) Prevent cluster of production EIPs from accidental release

You may also have a group of workload critical EIPs that you would like to secure from accidental release . For such use-cases, we would recommend to configure resource-level permissions within your CMP or SCP.

EIP supports resource-level permissions whereby you can define specific EIP ARN in addition to the supported condition key within your policy. This allows you to customize your policy that protects a specific cluster of EIPs from being accidentally released by an identity. As an example, below policy utilizes one of the supported condition keys: ResourceTag that prevents a group of EIPs with the tag “production: yes” from accidental release.

{
    "Version": "2012-10-17",
    "Statement": [
            {
            "Effect": "Deny",
            "Action": "ec2:ReleaseAddress",
            "Resource": "arn:aws:ec2:*:*:elastic-ip/*",
            "Condition": {
                "StringEquals": {"aws:ResourceTag/Production": "yes"}
            }
        }
    ]    
}

In action
As shown in figure 10, an user “Testaccount” trying to release an EIP that is tagged as “production = yes”. Because of the above policy attached, the user will receive an error like below.

           Figure 10: User trying to release EIP: 52.88.y.y/32 that is used for critical workload

We have other supported condition keys which you can utilize to customize the resource level permission per your requirement.

Allow a certain user, role, or group to release Elastic IPv4 addresses

We also understand you may face situations where you would like to release the Elastic IPv4 address. Currently, Public IPv4 is a scarce resource and we recommend to use them diligently. As you may already be aware, we recently announced a new charge for public IPv4 addresses whether attached to a service or not (there is already a charge for EIP addresses allocated in your account but unused by any AWS resources).

To avoid charges due to idle EIPs in your account, we highly recommend to release them when not in use. To achieve that, you can temporarily elevate the permission that would authorize the required user, role or group within an account to release the EIP addresses.

Note: If you have a SCP that Denies the ReleaseAddress Action and a CMP that Allows the ReleaseAddress action, the final evaluation would be Deny the action. Thus, you need to ensure both the policies Allows the identity to perform the action.

Step 1: Modify existing policy to Allow ReleaseAddress action as shown below

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Action": "ec2:ReleaseAddress",
"Resource": "*"
}
]
}

Step 2: Release the required EIP addresses either via AWS console or AWS CLI. You can also implement solution to monitor all unassociated EIPs across region and automatically release for you.

Step 3: Revert existing modified policy back to Deny ReleaseAddress action as shown below

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Deny",
"Action": "ec2:ReleaseAddress",
"Resource": "*"
}
]
}

Conclusion

By using Identity based policy or Service Control Policy, a blanket solution can be applied in managing your Elastic IP addresses from unintended release account wide or organization wide. You can also configure resource level permissions within CMP or SCP to only protect a group of EIPs. We strongly recommend using one of the proposed multi-region solutions to minimize service disruption and improve your cloud infrastructure reliability.  Further, we also recommend to release idle EIPs when not in use by elevating the permission of an identity temporarily. If you have any questions about this post, start a new thread on AWS re:Post, or contact AWS Support.