-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/28519/
-----------------------------------------------------------
(Updated Dec. 9, 2014, 10:55 a.m.)
Review request for Ambari, Jaimin Jetly, Jonathan Hurley, Jayush Luniya, Nate
Cole, Robert Nettleton, and Tom Beerbower.
Changes
-------
Requesting more reviewers knowlegable of agent-side code.
Bugs: AMBARI-8343
https://issues.apache.org/jira/browse/AMBARI-8343
Repository: ambari
Description
-------
In order to properly handle the automated installation or removal of a security
infrastructure (like Kerberos) in the cluster, Ambari needs to know whether
each component on the hosts of the cluster is properly _secured_ or not. This
information may be compared with data on the Ambari server to help determine
what steps should be taken to ensure the cluster is in the correct _secured_
state.
To do this, the current and desired component security state is maintained in
the Ambari database. The Ambari server will update the desired state details
according to whether the cluster is to be secured or not and whether the
relevant service has enough metadata to be secured. If the desired and actual
security state details do not match, the Ambari server will take the necessary
steps to work towards synchronization.
In order for a component to indicate its security status, a new property needs
to be returned in the `STATUS_COMMAND` response message (from the Ambari
agent). This property should be named ‘securityState’ and should have one of
the following values:
* `UNKNOWN` - Indicates that it is not known whether the service or component
is secured or not
* `UNSECURED` - Indicates service or component is not or should not be secured
* `SECURED_KERBEROS` - Indicates component is or should be secured using
Kerberos
* `ERROR` - Indicates the component is not secured due to an error condition
To properly set this state value, a call needs to be executed per component
querying for its specific state. Due to the differences on how each component
is secured and how it may be determined if security is setup what type is
configured, and working is it properly, it is necessary for each component to
have its own logic for determining this state. Therefore the ambari-agent
process will need to call into the component’s configured (lifecycle) script
and wait for its response - not unlike how it determines whether the component
is up and running.
After the infrastructure is in place, each service definition needs to be
updated to implement the new security status check function. The function
should perform the following steps:
* Determine if security is enabled or disabled
** If disabled, return "UNSECURED"
** If enabled, determine what type of security is enabled
*** If Kerberos is configured
**** Perform tests (kinit?, ping KDC?) to determine if the configuration
appears to be working
***** If working, return “SECURED_KERBEROS”
***** If not working, return “ERROR”
*** Else, return "UNKNOWN"
If no function is available, the Ambari agent should return “UNKNOWN”.
Diffs
-----
ambari-agent/src/main/python/ambari_agent/ActionQueue.py 4ecb822
ambari-agent/src/main/python/ambari_agent/CustomServiceOrchestrator.py
08dddae
ambari-agent/src/test/python/ambari_agent/TestActionQueue.py 034dba3
ambari-agent/src/test/python/ambari_agent/TestCustomServiceOrchestrator.py
24ee259
Diff: https://reviews.apache.org/r/28519/diff/
Testing
-------
Updated the following unit tests:
* ambari-agent/src/test/python/ambari_agent/TestCustomServiceOrchestrator.py
* ambari-agent/src/test/python/ambari_agent/TestActionQueue.py
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 03:06 min
[INFO] Finished at: 2014-11-27T15:35:18+00:00
[INFO] Final Memory: 80M/411M
[INFO] ------------------------------------------------------------------------
Thanks,
Robert Levas
