[
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
This file seemed to not have been picked up by the automated QA process
(Jenkins). Trying again.
Patch File [^AMBARI-8343_03.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
>
>
> 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)
