Repository navigation
API: sign requests by algorithm HmacSHA512 by default - #14457
weizhouapache wants to merge 1 commit into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## main #14457 +/- ##
=============================================
- Coverage 19.73% 3.70% -16.03%
=============================================
Files 6371 493 -5878
Lines 575734 42558 -533176
Branches 70470 8063 -62407
=============================================
- Hits 113594 1578 -112016
+ Misses 449793 40751 -409042
+ Partials 12347 229 -12118
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
|
@blueorangutan package |
|
@weizhouapache 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. |
|
Packaging result [SF]: ✔️ el8 ✔️ el9 ✔️ el10 ✔️ debian ✔️ suse15. SL-JID 19679 |
|
cloudmonkey suports it now: apache/cloudstack-cloudmonkey#213 |
|
@blueorangutan test |
|
@weizhouapache a [SL] Trillian-Jenkins test job (ol8 mgmt + kvm-ol8) has been kicked to run smoke tests |
Description
This PR adds support for
HmacSHA512when the API server verifies the signature of signed API requests (apiKey/secretKeyauthentication). Until now onlyHmacSHA1was accepted.Behaviour change
ApiServer.verifyRequest()computes the expected signature withHmacSHA512first, then falls back toHmacSHA1. The request is accepted if either matches.api.legacy.algorithm.supported(Advanced, global scope, dynamic, defaulttrue):true: bothHmacSHA512andHmacSHA1are accepted, so existing clients (CloudMonkey, cloudstack-go, Terraform provider and other third-party tools) keep working unchanged.false: onlyHmacSHA512is accepted. Requests signed withHmacSHA1are rejected.getComputedSignature(algorithm, secretKey, unsignedRequest), and the algorithm names are defined in the newcom.cloud.utils.security.Algorithmsclass.Security.addProvider(new BouncyCastleProvider())inApiServer.init()is removed. TheMaclookups here only use the default JCE providers.Compatibility
The default (
true) keeps full backward compatibility. Operators can setapi.legacy.algorithm.supported=falseonce all their API clients sign withHmacSHA512.Signing with
HmacSHA512is not applied on the client side by this PR. Client tools have to be updated to sign with it before the legacy algorithm can be disabled.Types of changes
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
Bug Severity
Screenshots (if appropriate):
How Has This Been Tested?
Test plan (to be run against a management server with this change):
HmacSHA1,api.legacy.algorithm.supported=true(default): acceptedHmacSHA512,api.legacy.algorithm.supported=true: acceptedHmacSHA512,api.legacy.algorithm.supported=false: acceptedHmacSHA1,api.legacy.algorithm.supported=false: rejected (HTTP 401 / "unable to verify user credentials")ApiServerHow did you try to break this feature and the system with this change?