Mailing-List: contact dev-help@ambari.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@ambari.apache.org
Date: Thu, 4 Dec 2014 18:32:12 +0000 (UTC)
From: "Robert Levas (JIRA)" <jira@apache.org>
To: dev@ambari.apache.org
Message-ID: <JIRA.12755616.1416068976000.77184.1417717932331@Atlassian.JIRA>
In-Reply-To: <JIRA.12755616.1416068976000@Atlassian.JIRA>
References: <JIRA.12755616.1416068976000@Atlassian.JIRA>
 <JIRA.12755616.1416068976328@arcas>
Subject: [jira] [Updated] (AMBARI-8343) Components should indicate Security
 State (via ambari-agent)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


     [ https://issues.apache.org/jira/browse/AMBARI-8343?page=3Dcom.atlassi=
an.jira.plugin.system.issuetabpanels:all-tabpanel ]

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

Updated unit tests to test failure cases.

Patch File [^AMBARI-8343_02.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
>
>
> In order to properly handle the automated installation or removal of a se=
curity 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 h=
elp determine what steps should be taken to ensure the cluster is in the co=
rrect _secured_ state.
> To do this, the current and desired component security state is maintaine=
d 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 whethe=
r the relevant service has enough metadata to be secured.  If the desired a=
nd actual security state details do not match, the Ambari server will take =
the necessary steps to work towards synchronization.=20
> 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 A=
mbari agent).  This property should be named =E2=80=98securityState=E2=80=
=99 and should have one of the following values:
> * {{UNKNOWN}} - Indicates that it is not known whether the service or com=
ponent 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 usin=
g Kerberos
> * {{ERROR}} - Indicates the component is not secured due to an error cond=
ition
> To properly set this state value, a call needs to be executed per compone=
nt querying for its specific state.  Due to the differences on how each com=
ponent is secured and how it may be determined if security is setup what ty=
pe is configured, and working is it properly, it is necessary for each comp=
onent to have its own logic for determining this state. Therefore the ambar=
i-agent process will need to call into the component=E2=80=99s 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 =E2=80=9CSECURED_KERBEROS=E2=80=9D
> ***** If not working, return =E2=80=9CERROR=E2=80=9D
> *** Else, return "UNKNOWN"
> If no function is available, the Ambari agent should return =E2=80=9CUNKN=
OWN=E2=80=9D.


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