You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@trafodion.apache.org by Gunnar Tapper <ta...@gmail.com> on 2016/02/05 22:57:10 UTC
Trafodion Runtime Security
Hi,
I'm trying to document introductory-level security requirements for
Trafodion, both runtime and during provisining
(installation/upgrade/resizing/removal).
This is what I have for runtime:
The `trafodion:trafodion` user ID is created as part of the installation
process. Trafodion runs under this ID, which must be
registered as a user in the Hadoop Distributed File System (HDFS) to store
and access objects in HDFS, HBase, and Hive.
In addition, the `trafodion` user ID required passwordless access among the
nodes where Trafodion is installed to run cross-node Trafodion functions
such as scripts.
Trafodion requires that either HDFS ACLs or Kerberos is enabled.
Trafodion users are managed by the Trafodion SQL security features (grant,
revoke, etc.), which can be integrated with LDAP if so desired.
These users are referred to as *database users* and do not have direct
access to the operating system.
What did I miss? What did I get wrong?
--
Thanks,
Gunnar
*If you think you can you can, if you think you can't you're right.*
RE: Trafodion Runtime Security
Posted by "D. Markt" <dm...@gmail.com>.
Are you asking about accessing HDFS files or something else? If it’s the former then yes they do work. But just like with Linux files it all depends on having users in groups. Otherwise if hbase owns the files and trafodion isn’t part of the same group the access options are limited. That is, either every user has the same access as trafodion via the “other” bits or you have to use ACLs to give trafodion access if the access will be via the trafodion userid. Trafodion tables are owned by the hbase userid but there appears to be cases when the process accessing some HDFS files use the trafodion userid.
--Dennis
From: Gunnar Tapper [mailto:tapper.gunnar@gmail.com]
Sent: Friday, February 12, 2016 12:31 AM
To: user@trafodion.incubator.apache.org
Subject: Re: Trafodion Runtime Security
I'll bite. Do the traditional Posix bits work under Trafodion?
Gunnar
On Wed, Feb 10, 2016 at 7:56 PM, Qifan Chen <qifan.chen@esgyn.com <ma...@esgyn.com> > wrote:
Should we also briefly mention if the traditional Posix permission bits does/does not work under trafodion?
thanks --Qifan
On Wed, Feb 10, 2016 at 8:16 PM, Hans Zeller <hans.zeller@esgyn.com <ma...@esgyn.com> > wrote:
Hi Gunnar, sounds good to me. Two somewhat related comments: One is that if Trafodion uses a floating IP address in a cloud deployment, like Amazon AWS, the trafodion id will need limited sudo capabilities to move the elastic IP address from one node to another.
The other is what we should not do: The trafodion id should not be given any other sudo privileges. Also, the trafodion id should be locked (sudo passwd -l trafodion). Users who need to be running as the trafodion id should do that using the sudo command, e.g. sudo -u trafodion -i.
Thanks,
Hans
On Fri, Feb 5, 2016 at 1:57 PM, Gunnar Tapper <tapper.gunnar@gmail.com <ma...@gmail.com> > wrote:
Hi,
I'm trying to document introductory-level security requirements for Trafodion, both runtime and during provisining (installation/upgrade/resizing/removal).
This is what I have for runtime:
The `trafodion:trafodion` user ID is created as part of the installation process. Trafodion runs under this ID, which must be
registered as a user in the Hadoop Distributed File System (HDFS) to store and access objects in HDFS, HBase, and Hive.
In addition, the `trafodion` user ID required passwordless access among the nodes where Trafodion is installed to run cross-node Trafodion functions such as scripts.
Trafodion requires that either HDFS ACLs or Kerberos is enabled.
Trafodion users are managed by the Trafodion SQL security features (grant, revoke, etc.), which can be integrated with LDAP if so desired.
These users are referred to as *database users* and do not have direct access to the operating system.
What did I miss? What did I get wrong?
--
Thanks,
Gunnar
If you think you can you can, if you think you can't you're right.
--
Regards, --Qifan
--
Thanks,
Gunnar
If you think you can you can, if you think you can't you're right.
Re: Trafodion Runtime Security
Posted by Gunnar Tapper <ta...@gmail.com>.
I'll bite. Do the traditional Posix bits work under Trafodion?
Gunnar
On Wed, Feb 10, 2016 at 7:56 PM, Qifan Chen <qi...@esgyn.com> wrote:
> Should we also briefly mention if the traditional Posix permission bits
> does/does not work under trafodion?
>
> thanks --Qifan
>
> On Wed, Feb 10, 2016 at 8:16 PM, Hans Zeller <ha...@esgyn.com>
> wrote:
>
>> Hi Gunnar, sounds good to me. Two somewhat related comments: One is that
>> if Trafodion uses a floating IP address in a cloud deployment, like Amazon
>> AWS, the trafodion id will need limited sudo capabilities to move the
>> elastic IP address from one node to another.
>>
>> The other is what we should not do: The trafodion id should not be given
>> any other sudo privileges. Also, the trafodion id should be locked (sudo
>> passwd -l trafodion). Users who need to be running as the trafodion id
>> should do that using the sudo command, e.g. sudo -u trafodion -i.
>>
>> Thanks,
>>
>> Hans
>>
>> On Fri, Feb 5, 2016 at 1:57 PM, Gunnar Tapper <ta...@gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm trying to document introductory-level security requirements for
>>> Trafodion, both runtime and during provisining
>>> (installation/upgrade/resizing/removal).
>>>
>>> This is what I have for runtime:
>>>
>>> The `trafodion:trafodion` user ID is created as part of the installation
>>> process. Trafodion runs under this ID, which must be
>>> registered as a user in the Hadoop Distributed File System (HDFS) to
>>> store and access objects in HDFS, HBase, and Hive.
>>> In addition, the `trafodion` user ID required passwordless access among
>>> the nodes where Trafodion is installed to run cross-node Trafodion
>>> functions such as scripts.
>>>
>>> Trafodion requires that either HDFS ACLs or Kerberos is enabled.
>>>
>>> Trafodion users are managed by the Trafodion SQL security features
>>> (grant, revoke, etc.), which can be integrated with LDAP if so desired.
>>> These users are referred to as *database users* and do not have direct
>>> access to the operating system.
>>>
>>>
>>> What did I miss? What did I get wrong?
>>>
>>> --
>>> Thanks,
>>>
>>> Gunnar
>>> *If you think you can you can, if you think you can't you're right.*
>>>
>>
>>
>
>
> --
> Regards, --Qifan
>
>
--
Thanks,
Gunnar
*If you think you can you can, if you think you can't you're right.*
Re: Trafodion Runtime Security
Posted by Qifan Chen <qi...@esgyn.com>.
Should we also briefly mention if the traditional Posix permission bits
does/does not work under trafodion?
thanks --Qifan
On Wed, Feb 10, 2016 at 8:16 PM, Hans Zeller <ha...@esgyn.com> wrote:
> Hi Gunnar, sounds good to me. Two somewhat related comments: One is that
> if Trafodion uses a floating IP address in a cloud deployment, like Amazon
> AWS, the trafodion id will need limited sudo capabilities to move the
> elastic IP address from one node to another.
>
> The other is what we should not do: The trafodion id should not be given
> any other sudo privileges. Also, the trafodion id should be locked (sudo
> passwd -l trafodion). Users who need to be running as the trafodion id
> should do that using the sudo command, e.g. sudo -u trafodion -i.
>
> Thanks,
>
> Hans
>
> On Fri, Feb 5, 2016 at 1:57 PM, Gunnar Tapper <ta...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I'm trying to document introductory-level security requirements for
>> Trafodion, both runtime and during provisining
>> (installation/upgrade/resizing/removal).
>>
>> This is what I have for runtime:
>>
>> The `trafodion:trafodion` user ID is created as part of the installation
>> process. Trafodion runs under this ID, which must be
>> registered as a user in the Hadoop Distributed File System (HDFS) to
>> store and access objects in HDFS, HBase, and Hive.
>> In addition, the `trafodion` user ID required passwordless access among
>> the nodes where Trafodion is installed to run cross-node Trafodion
>> functions such as scripts.
>>
>> Trafodion requires that either HDFS ACLs or Kerberos is enabled.
>>
>> Trafodion users are managed by the Trafodion SQL security features
>> (grant, revoke, etc.), which can be integrated with LDAP if so desired.
>> These users are referred to as *database users* and do not have direct
>> access to the operating system.
>>
>>
>> What did I miss? What did I get wrong?
>>
>> --
>> Thanks,
>>
>> Gunnar
>> *If you think you can you can, if you think you can't you're right.*
>>
>
>
--
Regards, --Qifan
Re: Trafodion Runtime Security
Posted by Hans Zeller <ha...@esgyn.com>.
Hi Gunnar, sounds good to me. Two somewhat related comments: One is that if
Trafodion uses a floating IP address in a cloud deployment, like Amazon
AWS, the trafodion id will need limited sudo capabilities to move the
elastic IP address from one node to another.
The other is what we should not do: The trafodion id should not be given
any other sudo privileges. Also, the trafodion id should be locked (sudo
passwd -l trafodion). Users who need to be running as the trafodion id
should do that using the sudo command, e.g. sudo -u trafodion -i.
Thanks,
Hans
On Fri, Feb 5, 2016 at 1:57 PM, Gunnar Tapper <ta...@gmail.com>
wrote:
> Hi,
>
> I'm trying to document introductory-level security requirements for
> Trafodion, both runtime and during provisining
> (installation/upgrade/resizing/removal).
>
> This is what I have for runtime:
>
> The `trafodion:trafodion` user ID is created as part of the installation
> process. Trafodion runs under this ID, which must be
> registered as a user in the Hadoop Distributed File System (HDFS) to store
> and access objects in HDFS, HBase, and Hive.
> In addition, the `trafodion` user ID required passwordless access among
> the nodes where Trafodion is installed to run cross-node Trafodion
> functions such as scripts.
>
> Trafodion requires that either HDFS ACLs or Kerberos is enabled.
>
> Trafodion users are managed by the Trafodion SQL security features (grant,
> revoke, etc.), which can be integrated with LDAP if so desired.
> These users are referred to as *database users* and do not have direct
> access to the operating system.
>
>
> What did I miss? What did I get wrong?
>
> --
> Thanks,
>
> Gunnar
> *If you think you can you can, if you think you can't you're right.*
>