[GitHub] [cloudstack] BryanMLima opened a new issue, #7369: Public IP quarantine feature

via GitHub Fri, 24 Mar 2023 10:48:10 -0700


BryanMLima opened a new issue, #7369:
URL: https://github.com/apache/cloudstack/issues/7369


   ##### ISSUE TYPE
   <!-- Pick one below and delete the rest -->
    * Feature Idea
   
   ##### COMPONENT NAME
   <!--
   Categorize the issue, e.g. API, VR, VPN, UI, etc.
   -->
   ~~~
   API, Public IP address
   ~~~
   
   ##### CLOUDSTACK VERSION
   <!--
   New line separated list of affected versions, commit ID for issues on main 
branch.
   -->
   
   ~~~
   4.18.0.2/Main
   ~~~
   
   
   ##### SUMMARY
   # Table of contents
   
   - [1. Problem description](#problem-description)
   - [2. Proposed changes](#proposed-changes)
       - [2.1. `updateQuarantinedIp` API](#updateQuarantinedIp-api)
       - [2.1. `removeQuarantinedIp` API](#removeQuarantinedIp-api)
       - [2.1. `listQuarantinedIp` API](#listQuarantinedIp-api)
       - [2.1. Changes to `associateIpAddress` and `disassociateIpAddress` 
APIs](#changes-apis)
   
   # <section id="problem-description">1. Problem description</section>
   
   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. 
   
   # <section id="proposed-changes">2. Proposed changes</section>
   
   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 <a 
href="#ip-quarantine-overview" class="internal-link">below</a>.
   
   <a name="ip-quarantine-overview">
       <img 
src="https://res.cloudinary.com/sc-clouds/image/upload/v1679516098/specs/ip-quarantine/ip-quarantine-overview_yrfpri.png";
           alt="ip-quarantine-overview"
           style="width: 70%;
           height: auto;">
   </a>
   
   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](#problem-description).
   
   
   | **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.                                                 |
   
   
   ## <section id="updateQuarantinedIp-api">`updateQuarantinedIp` API</section>
   API `updateQuarantinedIp` will have two parameters: `uuid` and `endDate` 
which are detailed in the table below. The figure 
[below](#update-quarantined-ip-flowchart) 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 |
   
   <a name="update-quarantined-ip-flowchart">
       <img 
src="https://res.cloudinary.com/sc-clouds/image/upload/v1679516098/specs/ip-quarantine/updateQuarantinedIp-flowchart_tg0tzo.png";
           alt="update-quarantined-ip-flowchart"
           style="width: 80%;
           height: auto;">
   </a>
   
   ## <section id="removeQuarantinedIp-api">`removeQuarantinedIp` API</section>
   API `removeQuarantinedIp` will have two parameters: `uuid` and 
`removalReason` which are detailed in the table below. The figure 
[below](#remove-quarantined-ip-flowchart) presents the flowchart for this API.
   
   <a name="remove-quarantined-ip-flowchart">
       <img 
src="https://res.cloudinary.com/sc-clouds/image/upload/v1679516098/specs/ip-quarantine/removeQuarantinedIp-flowchart_ilhdab.png";
           alt="remove-quarantined-ip-flowchart"
           style="width: 80%;
           height: auto;">
       <img src="">
   </a>
   
   | **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                             |
   
   
   ## <section id="listQuarantinedIp-api">`listQuarantinedIp` API</section>
   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. 
   
   ##  <section id="changes-apis">Changes to `associateIpAddress` and 
`disassociateIpAddress` APIs</section>
   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](#disassociation-ip-address-new-flow) presents the new changes to 
the disassociation of IP addresses.
   
   <a name="disassociation-ip-address-new-flow">
       <img 
src="https://res.cloudinary.com/sc-clouds/image/upload/v1679516098/specs/ip-quarantine/disassociateIps_qpd0kh.png";
           alt="disassociation-ip-address-new-flow"
           style="width: 80%;
           height: auto;">
       <img src="">
   </a>
   
   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](#allocate-ip-address-new-flow) 
summarizes the proposed new flow for the allocation of IP addresses.
   
   <a name="allocate-ip-address-new-flow">
       <img 
src="https://res.cloudinary.com/sc-clouds/image/upload/v1679516098/specs/ip-quarantine/allocate-ip-address-new-flow_a4pfrp.png";
           alt="allocate-ip-address-new-flow"
           style="width: 80%;
           height: auto;">
   </a>


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

[GitHub] [cloudstack] BryanMLima opened a new issue, #7369: Public IP quarantine feature

Reply via email to