Fixed User type accounts being able to change resource limits of their own domain and account

[erikbocks]

Description

The updateResourceLimit API, by default, is allowed only to the Root Admin, Domain Admin, and Resource Admin role types. These role types cannot change their account and domain limits using the API. However, if an account is created with a User type role, and the permission to this API is granted, they will be capable of changing their own account and domain resource limits and bypassing what has been allocated to them. In this scenario, the user could also cause a DoS by allocating all the resources (for instance, all the IP addresses).

This PR fixes this by implementing an account type validation that throws an exception if the caller's account is of type User.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• build/CI
• test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

Screenshots (if appropriate):

How Has This Been Tested?

In my local environment, a Modified User role was created, based on the default User role. Then, the permission to call the updateResourceLimit API was granted to it. A new account, named user, was created using the Modified User role. By default, this account had a limit of 20 Public IP to allocate.

I authenticated using the user account credentials in CMK, and executed this command, to unlimit the number of Public IP the user could allocate:

update resourceLimit account=user resourcetype=1 max=-1 domainid=<domain_id>

With that, the limitation was removed, and the user account can now exhaust the available public IPs in the environment. This also applies for the other limit types.

Besides changing the account limit, I could also change its domain limits by running the following command:

update resourceLimit resourcetype=1 max=-1 domainid=<domain_id>

The user with these permission cannot change the limits of other accounts within its domain or other domains' limits.

---

After testing that, I applied the updated packages to my local environment and executed the same commands, which resulted in errors as expected.

[codecov]

Codecov Report

❌ Patch coverage is 0% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 17.76%. Comparing base (40c8bc5) to head (97a6698).
⚠️ Report is 129 commits behind head on main.

Files with missing lines	Patch %	Lines
.../cloud/resourcelimit/ResourceLimitManagerImpl.java	0.00%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #12046      +/-   ##
============================================
+ Coverage     17.55%   17.76%   +0.21%     
- Complexity    15538    15859     +321     
============================================
  Files          5910     5923      +13     
  Lines        529334   530541    +1207     
  Branches      64654    64827     +173     
============================================
+ Hits          92905    94248    +1343     
+ Misses       425973   425749     -224     
- Partials      10456    10544      +88     

Flag	Coverage Δ
uitests	3.57% <ø> (-0.02%)	⬇️
unittests	18.85% <0.00%> (+0.23%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lucas-a-martins]

Maybe I'm missing something, but it seems that your test description explains the problem itself rather than how you tested the solution. Other than that, CLGTM.

[bernardodemarco]

@blueorangutan package

[blueorangutan]

@bernardodemarco a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress.

[bernardodemarco]

lgtm, I manually tested it in a local environment.

• Created an User account with a custom role with access to the updateResourceLimit API
• Tried to execute the API with the User account and verified that an error message was returned:

(u1) 🐱 > update resourcelimit resourcetype=1 max=10
🙈 Error: (HTTP 531, error code 4365) Your account does not have the right access level to update resource limits.
(u1) 🐱 > update resourcelimit resourcetype=1 max=-1
🙈 Error: (HTTP 531, error code 4365) Your account does not have the right access level to update resource limits.

[erikbocks]

Hello, @bernardodemarco and @lucas-a-martins

Thanks for the reviews, and @lucas-a-martins, thanks for the suggestion.

[blueorangutan]

Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 16304

[DaanHoogland]

@blueorangutan test

[blueorangutan]

@DaanHoogland a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests

[blueorangutan]

[SF] Trillian test result (tid-15150)
Environment: kvm-ol8 (x2), zone: Advanced Networking with Mgmt server ol8
Total time taken: 58324 seconds
Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr12046-t15150-kvm-ol8.zip
Smoke tests completed. 149 look OK, 1 have errors, 0 did not run
Only failed and skipped tests results shown below:

Test	Result	Time (s)	Test File
test_03_deploy_and_scale_kubernetes_cluster	Failure	40.22	test_kubernetes_clusters.py