A pagination limit should be enforced for large stack-list responses
With the addition of the management API stack-list functionality combined with the show_deleted parameter, it is now highly probable (almost certain) that a stack-list call could end up attempting to return hundreds of stacks. At a certain point Heat starts responding with a 500 error because the response it too large.
Along with this being a poor user experience it can also be exploited as an attack vector. Consider: a user spins up as many stacks as they can, then spams Heat with stack-list requests.
One of the easiest ways to address this would be to force a maximum limit. So, if no limit is specified in the request yet the response will exceed a maximum (say 100 stacks), then the user would automatically get a paginated response containing the first 100 stacks.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- Paul Nelson
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- New
- Series goal:
- None
- Implementation:
-
Unknown
- Milestone target:
-
next
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
We supports the stacks pagination now, what do you mean in this bp?
This is not about supporting pagination, this is about having no upward bound on how many stacks can be returned in a single call. I think the bp is pretty clear, but I'll try and rephrase.
Because we now have the ability to return all stacks for all tenants, it is possible to have a stack-list call return hundreds or even thousands of stacks. At best, this will result in a 500 error for the request. At worst, it will bring the Heat server to its knees, effectively causing a DoS attack.
So, if no limit is provided in the request, or the limit requested is too large, the maximum limit should be enforced. From experience, a maximum limit of 100 seems reasonable.
Another way to think about it: if a stack-list call does NOT specify a limit and the resulting response would be too large (e.g. great than 100 stacks), force pagination with a limit of 100. If a stack-list call DOES include a limit greater than the maximum (e.g. ?limit=500), enforce the maximum limit of 100.
Does that help clarify the reason for this bp?
kanagaraj-manickam: This is taken care by another blueprint https:/
