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 <[email protected]> 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.* >
