Public IP quarantine feature

[BryanMLima]

ISSUE TYPE

• Feature Idea

COMPONENT NAME

API, Public IP address

CLOUDSTACK VERSION

4.18.0.2/Main

SUMMARY

Table of contents

• 1. Problem description
• 2. Proposed changes
  • 2.1. updateQuarantinedIp API
  • 2.1. removeQuarantinedIp API
  • 2.1. listQuarantinedIp API
  • 2.1. Changes to associateIpAddress and disassociateIpAddress APIs

1. Problem description

Currently in Apache CloudStack (ACS) when a public IP address is released by a user, it (the public IP address) can be allocated by any other user in the Cloud. This can be a problem if the previous owner of the public IP has performed some illegal actions, which made the IP to be put on some blacklist. Moreover, if the IP is accidentally released, there is always the possibility that the previous owner is not able to allocate it again, which might be leveraged by some players to impersonate the previous owner's application and perform attacks.

2. Proposed changes

To address the problem described, we propose to introduce a new concept into ACS. The idea is to have a public IP quarantine process, where once the public IP is released, it can only be allocated by its previous owner for a given period (configurable, and where the default is 0 to maintain backward compatibility).

To implement the proposal we will create three new APIs: removeQuarantinedIp,updateQuarantinedIp and listQuarantinedIps. Only root and domain admins can use these new APIs. Moreover, a new table called quarantined_ips will be created in database cloud, and a global configuration called ip.address.quarantine.duration will be created defining the default value, in hours, of the IP to be quarantined. Moreover, the APIs associateIpAddress and disassociateIpAddress will be changed to support this feature. An overview of these changes is presented in the figure below.

The new table quarantined_ips will have seven columns in total which are presented in more detail in the table below. If the columns removed and removal_reason are null, then the IP address was not removed manually from quarantine. Furthermore, column previous_owner will be used when allocating any IP address. If the IP address is in quarantine, then, the caller can only allocate that IP address if it was the previous owner. Therefore, we remediate the problems described in Section 1.

Column	Nullable	Description
id	No	To identify the quarantine process
ip_address_id	No	To identify the IP address related to the quarantine
previous_owner	No	To identify the previous owner of the IP address
created	No	The date in which the quarantine was created
removed	Yes	The date in which the quarantine rule was removed manually by using the API removeQuarantinedIp
end_date	No	The date in which the IP will be available again
removal_reason	Yes	The reason for removing the IP from quarantine.

updateQuarantinedIp API

API updateQuarantinedIp will have two parameters: uuid and endDate which are detailed in the table below. The figure below presents the flowchart for this API.

Parameter	Description	Required	Value
uuid	The ID to identify the IP quarantined	Yes	An ID of a quarantined IP address
endDate	The date when the	Yes	Any date in the format yyyy-MM-dd‘T‘HH:mm:ssZ

removeQuarantinedIp API

API removeQuarantinedIp will have two parameters: uuid and removalReason which are detailed in the table below. The figure below presents the flowchart for this API.

Parameter	Description	Required	Value
uuid	The IP address to be removed from quarantine	Yes	The UUID of an existing IP address.
removalReason	The reason for removing the IP from quarantine	Yes	A string

listQuarantinedIp API

API listQuarantinedIp will not have any exclusive parameters beyond those from the BaseListCmd, and will only list the IP addresses which are quarantined. Domain admins will only be allowed to list quarantined IP addresses from their domain, and root admins will be able to list all quarantined IP addresses.

Changes to associateIpAddress and disassociateIpAddress APIs

The only way for an IP address to be quarantined is through the disassociateIpAddress API. After the IP is successfully disassociated, it will be added to the quarantined_ips table which will be unavailable to all users, except the previous owner. The IP will be assignable again to all users if it was removed manually, by the API removeQuarantinedIp, or by the value of the new global configuration ip.address.quarantine.duration. This configuration has a default value of 0 to maintain backward compatibility. The figure below presents the new changes to the disassociation of IP addresses.

For this feature to take effect, changes were needed in the process of allocation of IP addresses as well, specifically in the method assignAndAllocateIpAddressEntry. In this method, there is a verification to check if the IP is free; in the same method, a new verification will be introduced to check if this IP address is not in quarantine, i.e. the IP was never in quarantine or the removed or endDate columns are expired. If it is in quarantine, then the allocation is only allowed if the caller account was the previous owner. The figure below summarizes the proposed new flow for the allocation of IP addresses.

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[DaanHoogland]

@BryanMLima looks generally good, just one proposal of extension:
add a createQuarantinedIp or QuarantineIp so users can reserve an IP by asking the admin for it in advance of their deployment plans.
Easy win if it makes sense.

[BryanMLima]

Hello @DaanHoogland,

The concept of the quarantine is to retain the public IP for an account for a determined period after releasing it, which is useful when someone mistakenly releases an IP. For reserving it, we could use the API associateIpAddress.

[DaanHoogland]

associateIpAddress only works if the network already exists, but it is not important.