elbv2: respect UseExistingClientSecret #1270
Conversation
ansibullbot
added
WIP
This comment was marked as outdated.
This comment was marked as outdated.
|
Ah okey, the logic is nailed into an unittest...that needs some more work. |
Docs Build 📝Thank you for contribution!✨ This PR has been merged and your docs changes will be incorporated when they are next published. |
|
related to the
Just Technically the current However, this is an important PR, because the |
markuman
changed the title
this relates to ansible-collections/community.aws#604 |
Can you please open an issue for |
|
|
Does this PR close #1284? If so can you add |
No. It's something what need to be done in the future. |
tremble
added
mergeit
|
Build succeeded (gate pipeline). ✔️ ansible-galaxy-importer SUCCESS in 5m 07s |
Backport to stable-5: 💚 backport PR created✅ Backport PR branch: Backported as #1387 🤖 @patchback |
elbv2: respect UseExistingClientSecret SUMMARY Since amazon.aws 5.0.0, elb_application_lb runs into an exception, when using Type: authenticate-oidc in a rule, even when UseExistingClientSecret: True parameter is given. That works as expected with amazon.aws 4.x.x. The logic gets broken in #940 Basically AWS won't return both, UseExistingClientSecret and ClientSecret. But when requesting against boto3, both parameters are mutually exclusive! When the user set UseExistingClientSecret: True, the ClientSecret must be removed for the request. When the user does not set UseExistingClientSecret or set it to False, the UseExistingClientSecret must be included in the request. While diving deeper, I've noticed a basic change detection problem for default values, that are not requested, but AWS will return them. I've summerized it in #1284 However, this PR does not target #1284, it just fixes the exception and restores the functionality and hotfix the change-detection only for Type: authenticate-oidc. origin PR description The error was: botocore.errorfactory.InvalidLoadBalancerActionException: An error occurred (InvalidLoadBalancerAction) when calling the ModifyRule operation: You must either specify a client secret or set UseExistingClientSecret to true UseExistingClientSecret is not respected anymore since a.a 5 Introduced in #940 Furthermore, AWS returns also Scope and SessionTimeout parameters that are filled with default values if not requested. 'Scope': 'openid', 'SessionTimeout': 604800, That make the module always returns a change, if they are not requested. This fix does not break backwards compatibility, because the values are already set by aws, when not requested yet. ISSUE TYPE Bugfix Pull Request COMPONENT NAME plugins/module_utils/elbv2.yml ADDITIONAL INFORMATION - Conditions: - Field: host-header Values: - some.tld - Field: path-pattern Values: - "/admin/*" Actions: - Type: authenticate-oidc Order: 1 AuthenticateOidcConfig: Issuer: https://login.microsoftonline.com/32rw-ewad53te-ef/v2.0 AuthorizationEndpoint: https://login.microsoftonline.com/324re-dafs6-6tw/oauth2/v2.0/authorize TokenEndpoint: https://login.microsoftonline.com/432535ez-rfes-32543ter/oauth2/v2.0/token UserInfoEndpoint: https://graph.microsoft.com/oidc/userinfo ClientId: fasgd-235463-fsgd-243 ClientSecret: "{{ lookup('onepassword', 'some cool secret', vault='some important vault') }}" SessionCookieName: AWSELBAuthSessionCookie OnUnauthenticatedRequest: authenticate UseExistingClientSecret: True - TargetGroupName: "{{ some_tg }}" Type: forward Order: 2 Reviewed-by: Alina Buzachis Reviewed-by: Mark Chappell (cherry picked from commit c6906a3)
[PR #1270/c6906a3f backport][stable-5] elbv2: respect UseExistingClientSecret This is a backport of PR #1270 as merged into main (c6906a3). SUMMARY Since amazon.aws 5.0.0, elb_application_lb runs into an exception, when using Type: authenticate-oidc in a rule, even when UseExistingClientSecret: True parameter is given. That works as expected with amazon.aws 4.x.x. The logic gets broken in #940 Basically AWS won't return both, UseExistingClientSecret and ClientSecret. But when requesting against boto3, both parameters are mutually exclusive! When the user set UseExistingClientSecret: True, the ClientSecret must be removed for the request. When the user does not set UseExistingClientSecret or set it to False, the UseExistingClientSecret must be included in the request. While diving deeper, I've noticed a basic change detection problem for default values, that are not requested, but AWS will return them. I've summerized it in #1284 However, this PR does not target #1284, it just fixes the exception and restores the functionality and hotfix the change-detection only for Type: authenticate-oidc. origin PR description The error was: botocore.errorfactory.InvalidLoadBalancerActionException: An error occurred (InvalidLoadBalancerAction) when calling the ModifyRule operation: You must either specify a client secret or set UseExistingClientSecret to true UseExistingClientSecret is not respected anymore since a.a 5 Introduced in #940 Furthermore, AWS returns also Scope and SessionTimeout parameters that are filled with default values if not requested. 'Scope': 'openid', 'SessionTimeout': 604800, That make the module always returns a change, if they are not requested. This fix does not break backwards compatibility, because the values are already set by aws, when not requested yet. ISSUE TYPE Bugfix Pull Request COMPONENT NAME plugins/module_utils/elbv2.yml ADDITIONAL INFORMATION - Conditions: - Field: host-header Values: - some.tld - Field: path-pattern Values: - "/admin/*" Actions: - Type: authenticate-oidc Order: 1 AuthenticateOidcConfig: Issuer: https://login.microsoftonline.com/32rw-ewad53te-ef/v2.0 AuthorizationEndpoint: https://login.microsoftonline.com/324re-dafs6-6tw/oauth2/v2.0/authorize TokenEndpoint: https://login.microsoftonline.com/432535ez-rfes-32543ter/oauth2/v2.0/token UserInfoEndpoint: https://graph.microsoft.com/oidc/userinfo ClientId: fasgd-235463-fsgd-243 ClientSecret: "{{ lookup('onepassword', 'some cool secret', vault='some important vault') }}" SessionCookieName: AWSELBAuthSessionCookie OnUnauthenticatedRequest: authenticate UseExistingClientSecret: True - TargetGroupName: "{{ some_tg }}" Type: forward Order: 2 Reviewed-by: Mark Chappell
Disable galaxy-importer docs tests SUMMARY Because galaxy-importer tests the collections in a sterile environment it can't read the shared amazon.aws fragments. We're separately testing the docs more thoroughly using a github action, so we can disable the broken docs fragment testing via galaxy-importer ISSUE TYPE Feature Pull Request COMPONENT NAME tests/galaxy-importer.cfg ADDITIONAL INFORMATION
SUMMARY
Since amazon.aws 5.0.0,
elb_application_lbruns into an exception, when usingType: authenticate-oidcin a rule, even whenUseExistingClientSecret: Trueparameter is given. That works as expected with amazon.aws 4.x.x.The logic gets broken in #940
Basically AWS won't return both,
UseExistingClientSecretandClientSecret.But when requesting against boto3, both parameters are mutually exclusive!
When the user set
UseExistingClientSecret: True, theClientSecretmust be removed for the request.When the user does not set
UseExistingClientSecretor set it toFalse, theUseExistingClientSecretmust be included in the request.While diving deeper, I've noticed a basic change detection problem for default values, that are not requested, but AWS will return them. I've summerized it in #1284
However, this PR does not target #1284, it just fixes the exception and restores the functionality and hotfix the change-detection only for
Type: authenticate-oidc.origin PR description
UseExistingClientSecretis not respected anymore since a.a 5Introduced in #940
Furthermore, AWS returns also
ScopeandSessionTimeoutparameters that are filled with default values if not requested.That make the module always returns a
change, if they are not requested.This fix does not break backwards compatibility, because the values are already set by aws, when not requested yet.
ISSUE TYPE
COMPONENT NAME
plugins/module_utils/elbv2.yml
ADDITIONAL INFORMATION