-
Notifications
You must be signed in to change notification settings - Fork 304
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
HPCC-32968 Add ElasticSearch server security configuration values #19310
Conversation
Jira Issue: https://hpccsystems.atlassian.net//browse/HPCC-32698 Jirabot Action Result: |
b145e1b
to
20b4ea5
Compare
20b4ea5
to
625b88f
Compare
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.
helm/examples/metrics/README.md
Outdated
|
||
**Authentication** | ||
|
||
A child of the host configuration where authentication settings are defined. The settings are: |
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.
it's not clear if the authentication section is required or optional. It seems the type is optional, but if authentication is provided, the type seems necessary.
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.
Added wording to indicate it's optional
helm/examples/metrics/README.md
Outdated
A child of the host configuration where authentication settings are defined. The settings are: | ||
|
||
* type - Authentication type used to connect to the ElasticSearch server. Value defines the remaining settings. | ||
The allowed values are (optional) |
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.
based on above comment, type should be required if authentication is specified. otherwise if authentication is required, there should be a none option here
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.
Changed wording to indicate that type is required
|
||
// Get authentication settings, if present | ||
Owned<IPropertyTree> pAuthConfigTree = pSettingsTree->getPropTree("authentication"); | ||
if (pAuthConfigTree) |
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.
if !pAuthConfigTree could be handled the same way pAuthConfigTree handles it in L153
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.
If the tree is null, then no processing is needed. It seemed easier to read the positive case where the tree exists
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.
in terms of readability, returning false if !pAuthConfigTree is easier to read. as it stands, we don't know how that case is handled until the end of the if block
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.
I changed and pushed a new commit. However, if the auth config tree is missing, true is returned, not false since it's not an error.
if (secretTree == nullptr) | ||
{ | ||
WARNLOG("ElasticMetricSink: Unable to load secret tree '%s', from vault '%s'", credentialsSecretKey.str(), | ||
!credentialsVaultId.isEmpty() ? credentialsVaultId.str() : "n/a"); |
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.
the n/a seems fine, but it seems to differ from other similar cases where and empty string is provided in the output.
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.
I felt that an empty string was not sufficient because it required knowledge that absence of a value implies that no vault ID was provided. It could be confusing. Using "n/a" tells the user that the vault ID is not applicable.
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.
IF the error is that the vault id is empty, the single quoted empty string is most appropriate.
Update:
Unless, you're saying the vaultID doesn't matter in this scenario
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.
Absence of a vault ID is not an error. Absence of username and/or password is the error. The vault ID is informational to tell the user if attempting to retrieve from a vault (and which vault of course)
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.
ok, that seems more confusing to me. I wish we had a usability team to weigh in on these types of issues developers are typically not the best to judge.
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.
The API to retrieve the secret has an optional vault parameter. If present, the secret is retrieved from the vault. If absent, the secret is treated as a regular Kubernetes secret. Two different APIs would have been better. So, the vault is included in the log message to indicate if the retrieval was from a vault or not, 'n/a' in the latter case.
d80deec
to
b4abfb1
Compare
@rpastrana I have amended the last commit with changes as discussed. |
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.
seems ok
@ghalliday Please merge |
b4abfb1
to
6566d44
Compare
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.
A couple of trivial comments. Main question is whether passwords provided in the configuration file should be supported at all. There is a danger of promoting bad practices.
helm/examples/metrics/README.md
Outdated
<Environment> | ||
<Software> | ||
<metrics name="mymetricsconfig"> | ||
<sinks name="myelasticsink" type="elastic"> | ||
<settings period="30" ignoreZeroMetrics="1"> | ||
<host name="<hostname>" port="<port>" protocol="http|htps"/> | ||
<host domain="<domainname>" port="<port>" protocol="http|htps"> |
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.
https
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.
Fixed
# settings.host.authentication - authentication settings if authentication is enabled (optional) | ||
# settings.host.authentication.type - authentication type (determines remaining settings) (only 'basic' is supported) | ||
# settings.host.authentication.username - username for basic authentication (if not stored in a secret) | ||
# settings.host.authentication.password - password for basic authentication (if not stored in a secret) |
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.
Why is this supported? The password would be accessible in plain test.
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.
The code treats the password as encrypted using the same mechanism as when read from the environment.xml. If you feel the containerized version should always have the value in a secret then I can remove it. Should it be decided it can be provided directly, I updated the comment to reflect that it is encrypted.
Please advise if it should be removed in favor of always being a secret (see comment below on always loading as a secret)
# settings.host.authentication.username - username for basic authentication (if not stored in a secret) | ||
# settings.host.authentication.password - password for basic authentication (if not stored in a secret) | ||
# settings.host.authentication.credentialsSecret - name of secret containing username and password for basic authentication | ||
# settings.host.authentication.credentialsVaultId - vault id for secret containing username password for basic authentication |
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.
optional.
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.
Added optional
} | ||
else | ||
{ | ||
WARNLOG("ElasticMetricSink: Host configuration missing or invalid"); | ||
// if basic auth, username and password are stored directly in the configuration |
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.
should require configuration via a secret
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.
If a secret is required for the username and password, how would that work in a bare metal environment? Is it possible to load secrets for bare metal?
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.
Yes secrets can be supplied in bare-metal environments, either by placing a file in the correct directory, or by using hashicorp vault.
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.
Please squash. I will merge as is, but in general we should not bee supporting passwords in configuration.
Added new configuration values for ElasticSearch server security Signed-Off-By: Kenneth Rowland [email protected]
a90db54
to
400d590
Compare
@ghalliday squashed. Please merge |
Jirabot Action Result: |
Added new configuration values for ElasticSearch server security
Signed-Off-By: Kenneth Rowland [email protected]
Type of change:
Checklist:
Smoketest:
Testing: