You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ambari.apache.org by "Jayush Luniya (JIRA)" <ji...@apache.org> on 2018/08/21 06:19:00 UTC

[jira] [Updated] (AMBARI-23026) WEB type alerts authentication in Kerberos secured cluster

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

Jayush Luniya updated AMBARI-23026:
-----------------------------------
    Fix Version/s:     (was: 2.7.1)
                   3.0.0

> WEB type alerts authentication in Kerberos secured cluster
> ----------------------------------------------------------
>
>                 Key: AMBARI-23026
>                 URL: https://issues.apache.org/jira/browse/AMBARI-23026
>             Project: Ambari
>          Issue Type: Bug
>          Components: alerts
>    Affects Versions: 2.5.2, trunk, 2.6.2
>         Environment: Ambari 2.5.2
> Hortonworks HDP-2.5.3.0-37
>            Reporter: David F. Quiroga
>            Assignee: Sandor Molnar
>            Priority: Minor
>             Fix For: 3.0.0
>
>
> In a Kerberized cluster some web endpoints (App Timeline Web UI, ResourceManger Web UI, etc.) require authentication. Any Ambari alerts checking those endpoints must then be able to authenticate.
> This was addressed in AMBARI-9586, however the default principal and keytab used in the alerts.json is that of the "bare" SPNEGO principal HTTP/_HOST@REALM. 
>  My understanding is that the HTTP service principal is used to authenticate users to a service, not used to authenticate to another service.
> 1. Since most endpoints involved are Web UI, would it be more appropriate to use the smokeuser in the alerts?
> 2. This was first observed in Ranger Audit, the YARN Ranger Plug-in showed many access denied from HTTP user. [This post|https://community.hortonworks.com/content/supportkb/150206/ranger-audit-logs-refers-to-access-denied-for-http.html] provided some direction as to where those requests were coming from. We have updated the ResourceManger Web UI alert definition to use cluster-env/smokeuser_keytab and cluster-env/smokeuser_principal_name and this has resolved the initial HTTP access denied. 
>  Would it also be advisable to make the change in the other secure Web UI alert definitions?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)