Background
xCAT stateful provisioning (kickstart file for RHEL) and stateless provisioning (image tarball) include the root password hash inside, and they are exposed to a HTTP server. Here might be security issue.
To enforce the security consideration, it is required xCAT to offer a capability to send the root password hash in a secure method during the provisioning only.
Platform
stateful provision
In existing implementation for RHEL7,
when run nodeset <cn> osimage=xxx
, xCAT will generate the kickstart file and it will contains a line
rootpw --iscrypted <root password hash>
During the provisioning, anaconda
will get the kickstart file and generate the corresponding root in /etc/shadow
And with the 'secure root support' enhancement, nodeset
will do the following:
- To check if Secure root is enabled (define
secureroot=1
in tablesite
), if not, same as previous.
If yes, then there are possible two option:
1, User define `install` temporary password in `passwd` table, `nodeset` write temporary hash into kickstart file. [**Current not support**]
2, No `install` temporary password defined, no root password hash into kickstart file.
When the node is in the end of provisioning and running xCAT default postscript, remoteshell
will do the following:
- To check if Secure root is enabled (define
secureroot=1
in tablesite
), if not, same as previous.
If yes, then it send `getcredential xcat_secure_pw:root` to xCAT master, and update the `/etc/shadow` with the right hash
stateless provision
In existing implementation for RHEL7,
when run packimage xxx
, xCAT will update the <rootimagedir>/etc/shadow
with the and pack it into image, so the image contains the root password hash directly.
And with the 'secure root support' enhancement, packimage
will do the following:
- To check if Secure root is enabled (define
secureroot=1
in tablesite
), if not, same as previous.
If yes, then there are possible two option:
1, User define `install` temporary password in `passwd` table, `packimage` write temporary hash into `/etc/shadow`. [**Current not support**]
2, No `install` temporary password defined, no root password hash into `/etc/shadow` file.
When the node is in the end of provisioning and running xCAT default postscript, remoteshell
will do the following:
- To check if Secure root is enabled (define
secureroot=1
in tablesite
), if not, same as previous.
If yes, then it send `getcredential xcat_secure_pw:root` to xCAT master, and update the `/etc/shadow` with the right hash
Note: if you define /etc/shadow
file in the synclist of the osimage, you must use packiamge --nosyncfiles xxx
getcredential
is the existing API for compute node to get sensitive information form MN, it is secure enough, we just need to extend it to return the password hash per requesting.
DB related
Add a new site entry secureroot
for this feature.
secureroot: Using secure mode to transfer root password hash during the installation. (Only supports RHEL7.x) Default is 0.
Platform
- Support it for RHEL7 first
- Other Platform will use the same design, but lower priority
Other Design Considerations
-
The interface to get the password hash must be secure enough
- The client had to be verified to make sure it is from a managed compute node and with the privilege.
-
The interface must be extensible to support other user
-
To keep compatible, secure root capability is not enabled by default.
-
For some of the case, user might define
shadow
file into synclist. In such case,syncfiles
will be run afterremoteshell
and override the/etc/shadow
-
As we may need to support user change password after installation for stateful, so not to change password when
run updatenode
.
Limitation
In secure root mode, as no root password, the console cannot be login via the real password before remoteshell
executed.
And just mentioned in above, a workaround is to set install
temporary password for it. This password is not work during the provisioning.
Document
- man page for
site
- additional section for it in https://xcat-docs.readthedocs.io/en/stable/advanced/security/security.html#password-management
Out of Scope
Statelite provisioning other user password - Not support it now, just leave the API compatible.
News
- Apr 22, 2016: xCAT 2.11.1 released.
- Mar 11, 2016: xCAT 2.9.3 (AIX only) released.
- Dec 11, 2015: xCAT 2.11 released.
- Nov 11, 2015: xCAT 2.9.2 (AIX only) released.
- Jul 30, 2015: xCAT 2.10 released.
- Jul 30, 2015: xCAT migrates from sourceforge to github
- Jun 26, 2015: xCAT 2.7.9 released.
- Mar 20, 2015: xCAT 2.9.1 released.
- Dec 12, 2014: xCAT 2.9 released.
- Sep 5, 2014: xCAT 2.8.5 released.
- May 23, 2014: xCAT 2.8.4 released.
- Jan 24, 2014: xCAT 2.7.8 released.
- Nov 15, 2013: xCAT 2.8.3 released.
- Jun 26, 2013: xCAT 2.8.2 released.
- May 17, 2013: xCAT 2.7.7 released.
- May 10, 2013: xCAT 2.8.1 released.
- Feb 28, 2013: xCAT 2.8 released.
- Nov 30, 2012: xCAT 2.7.6 released.
- Oct 29, 2012: xCAT 2.7.5 released.
- Aug 27, 2012: xCAT 2.7.4 released.
- Jun 22, 2012: xCAT 2.7.3 released.
- May 25, 2012: xCAT 2.7.2 released.
- Apr 20, 2012: xCAT 2.7.1 released.
- Mar 19, 2012: xCAT 2.7 released.
- Mar 15, 2012: xCAT 2.6.11 released.
- Jan 23, 2012: xCAT 2.6.10 released.
- Nov 15, 2011: xCAT 2.6.9 released.
- Sep 30, 2011: xCAT 2.6.8 released.
- Aug 26, 2011: xCAT 2.6.6 released.
- May 20, 2011: xCAT 2.6 released.
- Feb 14, 2011: Watson plays on Jeopardy and is managed by xCAT!
- xCAT Release Notes Summary
- xCAT OS And Hw Support Matrix
- xCAT Test Environment Summary
History
- Oct 22, 2010: xCAT 2.5 released.
- Apr 30, 2010: xCAT 2.4 is released.
- Oct 31, 2009: xCAT 2.3 released.
xCAT's 10 year anniversary! - Apr 16, 2009: xCAT 2.2 released.
- Oct 31, 2008: xCAT 2.1 released.
- Sep 12, 2008: Support for xCAT 2
can now be purchased! - June 9, 2008: xCAT breaths life into
(at the time) the fastest
supercomputer on the planet - May 30, 2008: xCAT 2.0 for Linux
officially released! - Oct 31, 2007: IBM open sources
xCAT 2.0 to allow collaboration
among all of the xCAT users. - Oct 31, 1999: xCAT 1.0 is born!
xCAT started out as a project in
IBM developed by Egan Ford. It
was quickly adopted by customers
and IBM manufacturing sites to
rapidly deploy clusters.