[
https://issues.apache.org/jira/browse/AMBARI-23026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ishan Bhatt updated AMBARI-23026:
---------------------------------
Fix Version/s: (was: 2.7.0)
2.7.1
> 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: Robert Levas
> Priority: Minor
> Fix For: 2.7.1
>
>
> 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)
