You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geode.apache.org by Nilkanth Patel <ni...@gmail.com> on 2015/08/03 14:57:54 UTC
Is REST APIs test coverage missing in geode codebase?
Hello,
With the Geode code base, i can see REST APIs code base but do not find any
test coverage for it (Junit/Dunits). Have we missed to move REST APIs test
coverage to geode open source or am i missing something here. I prefer to
add this test coverage so one can make sure their change are as expected.
Thank you.
Nilkanth Patel.
Re: Is REST APIs test coverage missing in geode codebase?
Posted by Nitin Lamba <ni...@ampool.io>.
Hi John,
Thanks for your note. Comments inline below:
________________________________
From: John Blum <jb...@pivotal.io>
Sent: Friday, October 9, 2015 2:12 PM
To: Nitin Lamba
Cc: dev@geode.incubator.apache.org
Subject: Re: Is REST APIs test coverage missing in geode codebase?
Answers and comments in-line below...
On Fri, Oct 9, 2015 at 1:07 PM, Nitin Lamba <ni...@ampool.io>> wrote:
Hi,
Trying to revive this thread after a few months - does the Developer REST APIs have any tests, like those included in Management REST APIs?
Yes. In the original, "closed" codebase, the tests for the Developer REST API would most have been in tests/com/gemstone/gemfire/rest/internal/web/. I suspect there are a few others lurking elsewhere as related to the JSONFormatter and other classes in GemFire that the Developer REST API directly relies on.
Will these tests be contributed or are new ones required to be built for Geode? Having Apache code without tests may be undesirable in the long-run...
Also, management REST APIs should ideally be secured for release as it creates a vulnerability on the locator node - starts the REST APIs giving full access to the Geode cluster. Perhaps, GEODE-17 (Integrated Security) addresses that concern. If integrated security is not in scope for the first release, we should consider turning-off Management REST APIs by default.
The Management REST API is secured from a transport perspective (HTTPS). This was introduced in GemFire 8.1 by the M&M team in Pune. Of course, authorization is a whole other story and currently the Management REST API is no more secure than Gfsh. I.e. none of the Gfsh commands executed on a remote cluster (through the Manager) are secured either.
If I understand the docs correctly, enabling remote access still requires some additional settings/ command line arguments. Guess my question is more about the default setup (out-of-the-box) behavior than a conscious (insecure?!) setup that an admin may choose to do behind firewalls.
Once you authenticate, you have free reign on the GemFire cluster to execute any Gfsh command you wish (there is no distinction between read-only or admin with write level privileges Gfsh when it comes to the commands, e.g. 'list regions' vs. 'create|alter region'). So, until role-based security is implemented and enforced in the Manager for JMX clients (like Gfsh executing various commands), then the Management REST API will also be insecure as result. My understanding was that "security" (and in particular, "authorization") was going to be implemented in the Managerso that any tool accessing the Management system (Gfsh, and by extension the Management REST API) using JMX, HTTP or any mangement-level protocol would have security enforced.
Agree. Accessing Gfsh may still require ssh to locator/ manager node but management REST is even more dangerous in that regard - just an IP address to the node can grant access and full control to manipulate the cluster.
So, if you throw out, or disable the Management REST API, you might as well disable Gfsh, or rather disable the whole Management (JMX) interface. The GemFire MBeans can also be manipulated through JConsole/JVisualVM or programmatically with a Java-based JMX client as well. FYI.
Yes, I'm aware of using JMX to modify the cluster. Again, as a default behavior, we can consider either disabling it or at least putting in some basic authentication (jmx-manager-access-file, jmx-manager-password-file) so that it forces users to set this up at startup time.
Just trying to build good/ secure practice to start a cluster. Both of these (Mgmt REST, JMX) are more important for production installations; frankly, app developers shouldn't be bogged-down by this config initially, which is why turning-off these services by default may be worth considering until GEODE-17 is in place.
My $0.02
Thoughts?
-Nitin
________________________________________
From: Nilkanth Patel <ni...@gmail.com>>
Sent: Monday, August 3, 2015 5:57 AM
To: dev@geode.incubator.apache.org<ma...@geode.incubator.apache.org>
Cc: jblum@pivotal.io<ma...@pivotal.io>
Subject: Is REST APIs test coverage missing in geode codebase?
Hello,
With the Geode code base, i can see REST APIs code base but do not find any
test coverage for it (Junit/Dunits). Have we missed to move REST APIs test
coverage to geode open source or am i missing something here. I prefer to
add this test coverage so one can make sure their change are as expected.
Thank you.
Nilkanth Patel.
--
-John
503-504-8657
john.blum10101 (skype)
Re: Is REST APIs test coverage missing in geode codebase?
Posted by John Blum <jb...@pivotal.io>.
Answers and comments in-line below...
On Fri, Oct 9, 2015 at 1:07 PM, Nitin Lamba <ni...@ampool.io> wrote:
> Hi,
>
> Trying to revive this thread after a few months - does the Developer REST
> APIs have any tests, like those included in Management REST APIs?
>
Yes. In the original, "closed" codebase, the tests for the Developer REST
API would most have been in tests/com/gemstone/gemfire/rest/internal/web/.
I suspect there are a few others lurking elsewhere as related to the
JSONFormatter and other classes in GemFire that the Developer REST API
directly relies on.
> Also, management REST APIs should ideally be secured for release as it
> creates a vulnerability on the locator node - starts the REST APIs giving
> full access to the Geode cluster. Perhaps, GEODE-17 (Integrated Security)
> addresses that concern. If integrated security is not in scope for the
> first release, we should consider turning-off Management REST APIs by
> default.
>
>
The Management REST API is secured from a transport perspective (HTTPS).
This was introduced in GemFire 8.1 by the M&M team in Pune. Of course,
authorization is a whole other story and currently the Management REST API
is no more secure than *Gfsh*. I.e. none of the *Gfsh* commands executed
on a remote cluster (through the Manager) are secured either.
Once you authenticate, you have free reign on the GemFire cluster to
execute any Gfsh command you wish (there is no distinction between
read-only or admin with write level privileges *Gfsh* when it comes to the
commands, e.g. 'list regions' vs. 'create|alter region'). So, until
role-based security is implemented and enforced in the Manager for JMX
clients (like *Gfsh* executing various commands), then the Management REST
API will also be insecure as result. My understanding was that "security"
(and in particular, "authorization") was going to be implemented in the
Managerso that any tool accessing the Management system (Gfsh, and by
extension the Management REST API) using JMX, HTTP or any mangement-level
protocol would have security enforced.
So, if you throw out, or disable the Management REST API, you might as well
disable Gfsh, or rather disable the whole Management (JMX) interface. The
GemFire MBeans can also be manipulated through JConsole/JVisualVM or
programmatically with a Java-based JMX client as well. FYI.
> Thoughts?
>
> -Nitin
> ________________________________________
> From: Nilkanth Patel <ni...@gmail.com>
> Sent: Monday, August 3, 2015 5:57 AM
> To: dev@geode.incubator.apache.org
> Cc: jblum@pivotal.io
> Subject: Is REST APIs test coverage missing in geode codebase?
>
> Hello,
>
> With the Geode code base, i can see REST APIs code base but do not find any
> test coverage for it (Junit/Dunits). Have we missed to move REST APIs test
> coverage to geode open source or am i missing something here. I prefer to
> add this test coverage so one can make sure their change are as expected.
>
> Thank you.
> Nilkanth Patel.
>
--
-John
503-504-8657
john.blum10101 (skype)
Re: Is REST APIs test coverage missing in geode codebase?
Posted by Nitin Lamba <ni...@ampool.io>.
Hi,
Trying to revive this thread after a few months - does the Developer REST APIs have any tests, like those included in Management REST APIs?
Also, management REST APIs should ideally be secured for release as it creates a vulnerability on the locator node - starts the REST APIs giving full access to the Geode cluster. Perhaps, GEODE-17 (Integrated Security) addresses that concern. If integrated security is not in scope for the first release, we should consider turning-off Management REST APIs by default.
Thoughts?
-Nitin
________________________________________
From: Nilkanth Patel <ni...@gmail.com>
Sent: Monday, August 3, 2015 5:57 AM
To: dev@geode.incubator.apache.org
Cc: jblum@pivotal.io
Subject: Is REST APIs test coverage missing in geode codebase?
Hello,
With the Geode code base, i can see REST APIs code base but do not find any
test coverage for it (Junit/Dunits). Have we missed to move REST APIs test
coverage to geode open source or am i missing something here. I prefer to
add this test coverage so one can make sure their change are as expected.
Thank you.
Nilkanth Patel.