+1 to Ivan’s idea about adding extra param to IgniteSystemProperties.
> Ok, and what's about other VM arguments, not included to
> IgniteSystemProperties?
IMO all VM arguments should be considered sensitive except those annotated
with @IgniteSystemProperties(sensitive=false).
--
Regards,
Ok, and what's about other VM arguments, not included to
IgniteSystemProperties?
пт, 2 июл. 2021 г. в 09:27, Zhenya Stanilovsky :
>
> -1 for extra arg, +1 for Ivan`s upper proposal : @IgniteSystemProperty
> annotation.
> Look, someone will set some of IGNITE_* option and after possibly cluster
>
-1 for extra arg, +1 for Ivan`s upper proposal : @IgniteSystemProperty
annotation.
Look, someone will set some of IGNITE_* option and after possibly cluster
problems will give this logs into analysis and engineer can`t reproduce such a
case, cause no param is applied.
>An extra argument for
An extra argument for IgniteSystemProperty sounds reasonable.
-Val
On Thu, Jul 1, 2021 at 10:04 AM Ivan Daschinsky wrote:
> Ok, this can be excluded using blocklist-jvm-params.properties or just by
> providing and extra arg to annotation, as I have just suggested
>
> чт, 1 июл. 2021 г., 19:51
Ok, this can be excluded using blocklist-jvm-params.properties or just by
providing and extra arg to annotation, as I have just suggested
чт, 1 июл. 2021 г., 19:51 Valentin Kulichenko :
> Ivan,
>
> IP addresses (e.g. IGNITE_TCP_DISCOVERY_ADDRESSES) and file paths
> (e.g. IGNITE_CONFIG_URL) are
Ilya,
I don't think this is the best approach because there are so many
properties that contain so many different types of information. "All or
nothing" doesn't really fit here. We want to have the ability to exclude
sensitive information, but still print out internal settings that are
useful for
Why not mask the default known sensitive options using a blocklist?
On Thu, 1 Jul 2021, 22:24 Shishkov Ilya, wrote:
> Folks,
>
> > Maybe we should add an extra JVM option (e.g.
> IGNITE_FORCE_PRINT_VM_ARGUMENTS) which is 'false' by default,
> > but if set to 'true' then #ackVmOptions will print
Folks,
> Maybe we should add an extra JVM option (e.g.
IGNITE_FORCE_PRINT_VM_ARGUMENTS) which is 'false' by default,
> but if set to 'true' then #ackVmOptions will print VM arguments even if
sensitive data is restricted?
What do you think about an extra JVM option?
чт, 1 июл. 2021 г. в 19:51,
Ivan,
IP addresses (e.g. IGNITE_TCP_DISCOVERY_ADDRESSES) and file paths
(e.g. IGNITE_CONFIG_URL) are often considered sensitive information. Data
related to authentication (e.g. IGNITE_SSH_USER_NAME) is very likely to be
sensitive.
Once again - I would exclude any property that can contain
We can add add an extra param in annotation, that blocks param to be
printed, just set it to false by default and block it wheb set to true
чт, 1 июл. 2021 г., 19:45 Atri Sharma :
> What if we allowed a blocklist of parameters that are never printed?
>
> On Thu, 1 Jul 2021, 22:06 Valentin
What if we allowed a blocklist of parameters that are never printed?
On Thu, 1 Jul 2021, 22:06 Valentin Kulichenko, <
valentin.kuliche...@gmail.com> wrote:
> Not all of them are OK to be printed out. At the very least, we should have
> a mechanism to exclude some of them. I would still go with
Hi,
Maybe we should add an extra JVM option (e.g.
IGNITE_FORCE_PRINT_VM_ARGUMENTS) which is 'false' by default, but if set to
'true' then #ackVmOptions will print VM arguments even if sensitive data is
restricted?
чт, 1 июл. 2021 г. в 19:41, Ivan Daschinsky :
> > Not all of them are OK to be
> Not all of them are OK to be printed out
Could you give an example please? As for me, all of them are pretty harmless
чт, 1 июл. 2021 г., 19:36 Valentin Kulichenko :
> Not all of them are OK to be printed out. At the very least, we should have
> a mechanism to exclude some of them. I would
Not all of them are OK to be printed out. At the very least, we should have
a mechanism to exclude some of them. I would still go with opt-in rather
than opt-out though, but I guess that is up to a discussion.
-Val
On Thu, Jul 1, 2021 at 9:29 AM Ivan Daschinsky wrote:
> This is security
This is security through obscurity, an obvious and a well-known anti
pattern. I suppose that printing jvm options, that is registered by
@IgniteSystemProperty annotation is an ideal variant
чт, 1 июл. 2021 г., 19:25 Valentin Kulichenko :
> Folks,
>
> *Anything* that a user provides to the system
Folks,
*Anything* that a user provides to the system can potentially be considered
sensitive information. This includes the VM arguments. We can't predict
what exactly one can put there, so let's not make assumptions.
When dealing with security, we should be as conservative as possible. That
Hello Ivan,
> At least, we could just hide params that match a specific pattern
Yes, we can filter out all vm options that do not relate to Ignite, for
instance.
> Ilya, go ahead, file ticket and prepare a PR.
Please do not rush. Let's listen to other community members. This question
is about
AFAIK, this allows users to pass in custom VM options which may be undesirable.
On Thu, Jul 1, 2021 at 12:07 PM Zhenya Stanilovsky
wrote:
>
>
> +1 for reverting, can anybody (possibly ticket starter?) explain how jvm
> settings will rise some security problems ?
>
>
>
> >I suppose, that we
I suppose, that all normal users should not suffer from this restrictions.
Nobody will pass password using jvm options. It is absolutely insane,
normal users pass passwords using environment variables.
At least, we could just hide params that match specific pattern
Ilya, go ahead, file ticket
Hello,
Unfortunately, the user can pass its own system properties via JVM options
as follows: -DMY_SECRET_PASSWORD=123
It does not seem, this approach is the best one. However, the user should
have a "kostyl" in order to hide these properties and values in the log
file, IMHO.
Thanks,
S.
ср, 30
+1 for reverting, can anybody (possibly ticket starter?) explain how jvm
settings will rise some security problems ?
>I suppose, that we should revert this particular line. I don't understand
>who ever considers vm options as sensitive info.
>
>ср, 30 июн. 2021 г., 22:52 Shishkov Ilya <
I suppose, that we should revert this particular line. I don't understand
who ever considers vm options as sensitive info.
ср, 30 июн. 2021 г., 22:52 Shishkov Ilya :
> Hi Igniters,
>
> This feature [1, 2] prevents logging of the VM arguments when
> IGNITE_TO_STRING_INCLUDE_SENSITIVE option is
Hi Igniters,
This feature [1, 2] prevents logging of the VM arguments when
IGNITE_TO_STRING_INCLUDE_SENSITIVE option is set to false. Till now, method
IgniteKernal#ackVmArguments remains mostly the same [3].
Is this behaviour actual now? Often, we should be able to get from logs the
actual VM
23 matches
Mail list logo
