+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,
Kons
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 V
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 of
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, Va
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 user-s
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 Kuliche
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 op
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 prin
> 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 stil
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 through
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
said
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 sec
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 and
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 и
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 set
18 matches
Mail list logo
