security-udp-dhalgo is new and is described here:
https://cwiki.apache.org/confluence/display/GEODE/Secure+UDP+Communication+in+Geode
Le 9/26/2016 à 11:23 AM, Swapnil Bawaskar a écrit :
Hi John,
security-manager and security-post-processor are discussed here:
https://cwiki.apache.org/confluence/display/GEODE/Geode+Integrated+Security
On Mon, Sep 26, 2016 at 11:01 AM, Joey McAllister <jmcallis...@pivotal.io>
wrote:
Hi John,
They are documented in the docs dev branch and will be published with the
next Geode release. Also, we're scheduled to donate the docs code to the
project later this week, so you'll be able to see the work in dev.
Best,
Joey
On Mon, Sep 26, 2016 at 10:41 AM John Blum <jb...@pivotal.io> wrote:
Jinmei-
Where are the following security-* properties documented?
security-udp-dhalgo
security-manager
security-post-processor
They certainly are not documented in the (Geode) User Docs, here
<
http://geode.docs.pivotal.io/docs/reference/topics/gemfire_
properties.html
[1].
Thanks!
John
[1]
http://geode.docs.pivotal.io/docs/reference/topics/gemfire_
properties.html
On Mon, Sep 26, 2016 at 8:42 AM, Jinmei Liao <jil...@pivotal.io> wrote:
Actually, I looked into the the config settings, these are the list of
settings that begin with security-. SSL settings are not there. The
security-client-* and security-peer-* are deprecated, so they don't
need
to
be in the cluster config. What about the udp-dhalgo and log-file and
log-level? Does it hurt to put them in the cluster-config?
"security-client-authenticator";
"security-client-accessor";
"security-client-accessor-pp";
"security-client-auth-init";
"security-client-dhalgo";
"security-peer-auth-init";
"security-peer-authenticator";
"security-peer-verifymember-timeout";
"security-udp-dhalgo";
"security-log-file";
"security-log-level";
"security-manager";
"security-post-processor";
On Fri, Sep 23, 2016 at 12:41 PM, Bruce Schuchardt <
bschucha...@pivotal.io
wrote:
SSL settings and the new UDP dhAlgo setting can't be in the cluster
config. The cluster config is received over TCP/IP so you would have
to
use unsecured information to retrieve the settings, and you'd have to
do
it
before the cache is created.
Does the security-manager have any role to play prior to the cache
being
created? For instance, is it involved in authenticating the receipt
of
a
new membership view or a join request in GMSAuthenticator? If so you
can't
store it in the cluster config, which is only retrieved later on
during
cache creation.
Le 9/23/2016 à 11:57 AM, Michael Stolz a écrit :
I am in favor of keeping the SSL thoughts separate from the RBAC
thoughts,
but I don't see any reason they couldn't share the same repository.
That said though, does putting it all into the Cluster Configuration
Manager (CCM) make it so that you can only have security if you are
using
CCM for configuration?
--
Mike Stolz
Principal Engineer, GemFire Product Manager
Mobile: 631-835-4771
On Fri, Sep 23, 2016 at 1:48 PM, Jinmei Liao <jil...@pivotal.io>
wrote:
Hi, All,
I am working on this ticket:
https://issues.apache.org/jira/browse/GEODE-1659. Basically,
currently,
any
member(locator or server) needs to specify its own security-manager
in
order to protect its data which could leads to misconfiguration and
data
leak. So we would like to put it into the cluster configuration so
any
member who wants to join the cluster will need to apply the same
security
measures.
Now Here is my question, should we only put the "security-manager"
and
"security-post-processor" in the cluster config or any "security-*"
settings, which include SSL settings as well.
Thanks!
--
Cheers
Jinmei
--
Cheers
Jinmei
--
-John
503-504-8657
john.blum10101 (skype)
