elb_application_lb: rules behavior #1284
Comments
|
Files identified in the description: If these files are inaccurate, please update the |
ansibullbot
added
bug
|
One other possibility rather than introduce a new control parameter might be to documentate any single option for the rules parameter ... |
softwarefactory-project-zuul bot
pushed a commit
that referenced
this issue
Feb 23, 2023
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
patchback bot
pushed a commit
that referenced
this issue
Feb 23, 2023
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)
softwarefactory-project-zuul bot
pushed a commit
that referenced
this issue
Feb 23, 2023
[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
abikouo
pushed a commit
to abikouo/amazon.aws
that referenced
this issue
Sep 18, 2023
Rename KMS modules SUMMARY In line with the naming guidelines, rename aws_kms and aws_kms_info ISSUE TYPE Feature Pull Request COMPONENT NAME plugins/modules/aws_kms.py plugins/modules/aws_kms_info.py plugins/modules/kms_key.py plugins/modules/kms_key_info.py ADDITIONAL INFORMATION Reviewed-by: Joseph Torcasso <None> Reviewed-by: Alina Buzachis <None>
abikouo
pushed a commit
to abikouo/amazon.aws
that referenced
this issue
Sep 18, 2023
Rename KMS modules SUMMARY In line with the naming guidelines, rename aws_kms and aws_kms_info ISSUE TYPE Feature Pull Request COMPONENT NAME plugins/modules/aws_kms.py plugins/modules/aws_kms_info.py plugins/modules/kms_key.py plugins/modules/kms_key_info.py ADDITIONAL INFORMATION Reviewed-by: Joseph Torcasso <None> Reviewed-by: Alina Buzachis <None>
abikouo
pushed a commit
to abikouo/amazon.aws
that referenced
this issue
Oct 24, 2023
Rename KMS modules SUMMARY In line with the naming guidelines, rename aws_kms and aws_kms_info ISSUE TYPE Feature Pull Request COMPONENT NAME plugins/modules/aws_kms.py plugins/modules/aws_kms_info.py plugins/modules/kms_key.py plugins/modules/kms_key_info.py ADDITIONAL INFORMATION Reviewed-by: Joseph Torcasso <None> Reviewed-by: Alina Buzachis <None>
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Summary
The current handling of rules might be resulting always in a changing task.
That depends on action types where boto3 is assuming default values when they are not requested (See https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/elbv2.html and search for
The default is).For example, take action type
authenticate-oidcUser request
AWS response for describe rules
Module change detect
Note:
ClientSecretandUseExistingClientSecretare popped due postprocessing in that case, because AWS won't return none of them, but required one of them.- 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 + Scope: openid SessionCookieName: AWSELBAuthSessionCookie + SessionTimeout: 604800 OnUnauthenticatedRequest: authenticate - TargetGroupName: "{{ some_tg }}" Type: forward Order: 2changedwhen not all defaults value a givenPoint
2.is a very difficult one, because on the one hand, it is a bug. It can result in an unexpected change, e.g. when some properties were set to none-default values via cloudformation, terraform, cdk or even clicked. They got reset to defaults.But fixing it would also break backwards compatibility :) Because "use the defaults for all values that are not given" is the current behaviour.
I think a control parameter must be introduced, where you can say:
Issue Type
Bug Report
Component Name
elb_application_alb
Ansible Version
Collection Versions
AWS SDK versions
Configuration
$ ansible-config dump --only-changedOS / Environment
No response
Steps to Reproduce
see summary
Expected Results
see summary
Actual Results
Code of Conduct
The text was updated successfully, but these errors were encountered: