[ 
https://issues.apache.org/jira/browse/AMBARI-8343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robert Levas updated AMBARI-8343:
---------------------------------
    Attachment: AMBARI-8343_03.patch

Trying to initiate a new QA test run which failed due to issues external to my 
patch.

> Components should indicate Security State (via ambari-agent)
> ------------------------------------------------------------
>
>                 Key: AMBARI-8343
>                 URL: https://issues.apache.org/jira/browse/AMBARI-8343
>             Project: Ambari
>          Issue Type: New Feature
>          Components: ambari-agent
>    Affects Versions: 2.0.0
>            Reporter: Robert Levas
>            Assignee: Robert Levas
>            Priority: Critical
>              Labels: kerberos, states
>             Fix For: 2.0.0
>
>         Attachments: AMBARI-8343_01.patch, AMBARI-8343_02.patch, 
> AMBARI-8343_03.patch, AMBARI-8343_03.patch, AMBARI-8343_03.patch
>
>
> 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”.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to