Splunk 小课堂

第二课:Splunk的认证机制

难度:入门级

摘要:

Splunk的访问控制是基于角色的,这种机制对Splunk中的数据提供了一种灵活并有效的保护。讲一个小例子,大家都用过Splunk,都知道默认装好后,可以用admin/changme登进去,然后执行一个search,那么这个过程其实就是一个认证和授权的过程。这个过程涉及到三个非常基本且核心的概念:用户、角色和访问权限。认证决定了一个用户是不是他声称的这个人,而授权则在一个用户经过认证之后决定哪些资源可以被访问。

在今天的小课堂上,让我们先看看Splunk中的认证机制。下一堂课中我们会讲解授权机制。

讲师:

《Splunk小课堂》

勇哥

Just a tester.

 

Splunk的认证机制

Splunk安装好以后,会启用一种称之为Native Authentication的认证机制。在摘要提到的例子中,用admin/changeme的登录就是利用的这种认证机制,这种认证机制本质上就是一组用户名和密码对,就像linux上的用户名和密码对,这些用户名和密码在Splunk里边是通过配置文件来管理的。

但是,对于部署了其他服务的企业信息系统而言,这种认证方式并不易于维护和扩展。除了Splunk原生的认证机制之外,强大的Splunk同时还支持另外几种认证机制,可以让用户利用现有的一些认证服务来管理Splunk的认证,以及实现单点登录,下面我们将分别来聊一聊:

LDAP认证

LDAP是一个非常成熟并且广泛使用的认证协议,它可以集中的管理一个企业的用户信息并提供给所有兼容的服务使用。对于已经兼容LDAP认证服务的 IT 系统而言,可以非常简单地用LDAP对Splunk做认证。

基于LDAP的认证过程比较简单直观。首先,我们需要把LDAP里边的用户和组的信息同步到Splunk里边(之后LDAP协议会保证两边信息的一致性)。然后把Splunk的角色和LDAP组之间做映射,因为虽然我们的认证交给了LDAP,但是认证过的用户可以访问哪些资源,主要通过角色和访问权限来控制,这个我们会放在后面的授权部分来介绍。

配置步骤

《Splunk小课堂》

在settings->Access controls菜单下,可以找到Authentication method菜单,在这里我们选择LDAP, 然后点击下面的链接。

《Splunk小课堂》

输入要配置的LDAP Server的信息:

《Splunk小课堂》

保存成功后,在Actions这一栏点击Map groups。文章开头我们提到过Splunk的访问控制是基于角色的,这里的角色是指Splunk里的角色,所以在LDAP中的用户同步过来后,需要把他们映射到Splunk的一些角色上,才可以访问Splunk里边的资源。

《Splunk小课堂》

通过以上几个简单的步骤,Splunk认证完全托管给已有的LDAP服务。

但是,这种认证方式并不是时下流行的单点登录(SSO)。接下来,我们来看一种流行的单点登录配置。

基于SAML认证

SAML2.0定义了一些SSO Profile用来支持特定的用户场景,下图的流程图展示了Splunk支持的一种认证流程(基于Ping Federate),这种认证流程是Web Browser SSO Profile中的一个认证流程

《Splunk小课堂》

这个图分为三部分,左上角是一个SP,在SAML的protocol里边,他负责跟IDP(就是用来做单点登录认证的服务)进行通信。SP由两部分组成,一个Splunk,一个ACS(Assertion Consumer Service)。通过配置,Splunk通过这个ACS和IDP通信。这个图是一个逻辑上的概念,因为在我们实际的部署中,这个ACS通常和IDP配置在同一个Ping Federate服务器上,当然可以在单独的Ping Federate服务器上配置。在右边这个方框里,也有两部分,一个是负责提供SSO service,另外还有一个可选的User Store负责存储用户的信息,在我们的例子中,它是一个Microsoft Service。

前面提到了SAML2.0里的Web Browser SSO Profile,这个Profile定义了很多认证的工作流程,Splunk支持的登录流程是由SP发起的。在我们的例子里是由Splunk通过ACS发起的,也就是说这个登录过程里,我们一开始访问的是Splunk,但是这和SSO中提到的单点登录冲突。在我们的场景里,虽然我们开始访问的是Splunk,但是Splunk并不会给你呈现一个登录界面,Splunk会跟ACS通信,会把请求redirect到IDP这边,在IDP提示用户输入credentials,IDP就是这个配置中唯一的登录点。在这个页面上,通常你也看不到和Splunk相关的信息,完成认证后,IDP会返回一个SAML response,浏览器自动把这个IDP认证后的SAML response再post回和Splunk绑定的ACS做验证。如果SAML response没问题,最后浏览器会被重定向到Splunk,这个时候用户就会看到一个登录后的Splunk。

登录的页面由IDP提供,这个是跟之前的LDAP认证最直观的一个不同点。需要注意的另外一点是,在配置了SSO以后,Splunk原有的native认证就失效了,因为此时唯一的登录点变成了IDP的登录界面,IDP管理的用户认证信息和Splunk native认证管理的用户认证信息是完全独立的。

配置步骤

假设我们已经基于Ping Federate 配置好了一个IDP,接下来我们需要把Splunk变成一个SP。这个需要在Splunk跟Ping Federate两边同时做配置。在Ping Federate端,我们需要创建一个SP Connection,有两个地方需要配置,首先选择Browser SSO Connection Type:

《Splunk小课堂》

同时勾选SP-Initiated SSO, SP-Initiated SLO:

《Splunk小课堂》

其他的步骤请参考Ping Federate的文档,最后会得到这样一个SP:

《Splunk小课堂》

在Splunk端我们同样需要这样一个配置,在settings -> Access controls -> Authentication methods下面,我们选择SAML authentication, 输入之前在SP端配置的信息:

《Splunk小课堂》

保存后,同样需要把SAML中的组映射到Splunk的角色:

《Splunk小课堂》

需要注意的是,IDP中的组信息(图中的Splunk_test)并不会自动同步给Splunk,需要手动输入,通过以上配置,Splunk的认证就会由IDP接管。

Scripted 认证

如果以上两种认证方式依然无法满足企业部署的需要,Splunk还提供了另外一种更为灵活的机制用于扩展系统的用户认证——Scripted。Scripted认证就是把认证的部分完全交给一个Python Script,用户可以根据自己的需要以编程的方式实现认证,比如通过REST API访问一些在线的认证服务,或者访问现有的用户管理系统。

首先我们来看看一个Python Script中的代码段,

# keys we’ll be using when talking with splunk.

USERNAME    =“username”

USERTYPE    =“role”

SUCCESS     =“–status=success”

FAILED      =“–status=fail”

 

# Maps users to roles – All users must be lowercase

# Roles should be lowercase as well, but there’s some uppercasefor testing

umap = { ‘scriptedadmin’ : [‘admin’,‘user’,‘foo’],

         ‘foobar’ : [‘user’],

         ‘upperuser’ : [‘UsEr’] }

 

defuserLogin( args ):

    #Everyone’s password is ‘changeme’

    if args[USERNAME] in umap and args[‘password’] ==‘changeme’:

        returnSUCCESS

    else:

        returnFAILED

 

defgetUserInfo( args ):

    # Usethe same name for userId (deprecated), username, realname

    un = args[USERNAME]

    if un in umap:

        returnSUCCESS+‘–userInfo=’+ un +‘;’+ un +‘;’+ un +‘;’+‘:’.join(umap[un])

    else:

        returnFAILED

 

defgetUsers( args ):

    out =SUCCESS

    for u, r inumap.iteritems():

        out +=‘–userInfo=’+ u +‘;’+ u +‘;’+ u +‘;’+‘:’.join(r)

 

    return out

这里有3个基本的方法需要实现,userLogin, getUserInfo, getUsers, 关于这三个方法的详细定义如下:

  • userLogin, 这个方式在用户login的时候会被访问,实现了登录的主要逻辑。

  • getUserInfo, 在用户登录后,这个方法用来返回用户的详细信息。Splunk基于收到的用户角色信息决定用户可以访问哪些资源

  • getUsers,,返回所有用户列表。这个方法返回所有的用户信息,用以在权限管理相关页面显示,比如设置App权限。

 

在创建了authentication script之后,我们需要修改一个配置文件来启用Scripted认证。在<SPLUNK_HOME>/etc/system/default文件夹下有一个autentication.conf,修改authentication和script stanza如下:

[authentication]

authType = Scripted

authSettings = script

 

[script]

scriptPath = “$SPLUNK_HOME/bin/python“”path_to_your.py”

然后重启Splunk,这里需要注意的是,虽然我们启用了Scripted认证,但是和LDAP认证一样,native认证依然生效。

以上只是列出了Splunk支持的4种常用的认证方式,当然Splunk支持的认证方式更多,Splunk的官方文档列出了更为详尽的认证配置,请参考这里:

Quiz

看看这期的内容你消化了多少?来做几道小测试题吧!

  1. 在配置Splunk使用LDAP认证和SAML认证时,需要映射LDAP Server或SAML IDP的角色到Splunk的Roles吗?

    A. 是

    B. 否

  2. 文中提到的LDAP认证是一种单点登录(SSO)配置吗?

    A. 是

    B. 否

  3. 启用了以下哪种认证后,Splunk的native认证就不起作用了?

    A. LDAP认证

    B. SAML认证

    C. Scripted认证

 

《Splunk小课堂》