-
Notifications
You must be signed in to change notification settings - Fork 582
set deny_null_bind default to true #2622
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
@aahel Hello, thanks for the PR! I am wondering why this doesn't work without your change. Everything looks correct:
Do you know why this isn't working? |
|
Oh, I think this is happening because we are ignoring the error here
That said, I think setting the Default in TFVP is ok in this case. |
this was making it send false (default value of bool field) to the api. Now using CustomizeDiff i am forcing the |
fairclothjm
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
fairclothjm
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
set deny_null_bind default to true (hashicorp#2622)
Description
Currently if the user does not set
deny_null_bindin tf config we send false to the vault api. This creates an insecure config.In this pr we are setting
deny_null_bindtotrueif its not provided in tf configThis prevents users from bypassing authentication when providing an empty password. It also makes it compliant with vault's default behaviour.
jira:- https://hashicorp.atlassian.net/browse/SECVULN-29861
Manual testing
Testing that
deny_null_bindgets set totruewhen not provided in tf configBefore the change
After the Change
Checklist
Output from acceptance testing:
Community Note
PCI review checklist
I have documented a clear reason for, and description of, the change I am making.
If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.
If applicable, I've documented the impact of any changes to security controls.
Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.