Fixed
Pinned fields
Click on the next to a field label to start pinning.
Details
Assignee
James LeeJames LeeReporter
James LeeJames LeeIs this a Regression?
YesTriage
UntriagedDue date
Jun 23, 2023Story Points
0Priority
MajorInstabug
Open Instabug
Details
Details
Assignee
James Lee
James LeeReporter
James Lee
James LeeIs this a Regression?
Yes
Triage
Untriaged
Due date
Jun 23, 2023
Story Points
0
Priority
Instabug
Open Instabug
PagerDuty
PagerDuty
PagerDuty
Sentry
Sentry
Sentry
Zendesk Support
Zendesk Support
Zendesk Support
Created April 5, 2023 at 3:55 PM
Updated December 9, 2024 at 2:58 PM
Resolved June 22, 2023 at 12:43 PM
What's the issue?
In 7.1.0 we introduced the ability to authenticate with the cluster using client certificate authentication (mTLS).
Part of this change, was that users could now either supply a username/password pair, or mTLS related flags (e.g. client cert/key).
Given these flags are all used when we create a REST client, the natural home for this validation was our
rest_initiliser
decorator (source).We missed the case where it's valid to not supply any credentials at all; this results in the false positive where flag validation kicks in, requiring the user to supply a username/password when it's not necessary.
What's the fix?
We should add a condition to the initializer that allows certain sub-commands to not have any authentication flags provided.
We should verify that we haven't made any new assumptions that at least one of these authentication methods will be provided.
We should go through the supported commands and make sure that - where required - authentication flags are made optional.
Is there a workaround?
Prior to the cluster being initialized, you can use placeholders for the username/password.
After the cluster has been initialized, the actual username/password must be supplied.
Affected sub-commands
node-init