二丫讲梵
二丫讲梵
2019-11-03
目录

集成Zabbix,Jenkins,GitLab,JumpServer,Harbor,Nginx实战

文章发布较早，内容可能过时，阅读注意甄别。

网上有很多文章，都是在介绍了部署之后，就完事儿了，真正系统认真地把实际应用场景中的配置内容分享的，则是少之又少，有分享的，也都是含糊不清，让人难以学习，这里我特别将日常生产中常用的一些软件配置方式，一一过了一遍，并整理分享，愿阅读本篇文章的你能有所收获。

另外，我所分享出来的，可能只是我个人的一种思路方案，如果您有更加简便合理的方案，欢迎留言分享交流！

# 1，zabbix配置LDAP

zabbix在配置起来是比较简单的，我们直接使用最外层的用户授权即可，亦即不用过分深入再对用户进行分组管理，因为zabbix自身还会有一层授权控制。

那么所有的配置如下图所示：

image-20191020233943407

说明：

  • 认证方式：选择LDAP。
  • LDAP主机：可以填IP，这里我写了配置LDAP时用的域名，注意记得将此域名写入到本机hosts解析。
  • 端口：默认389.
  • 基于DN：此处填写 ou=People,dc=eryajf,dc=net，表示用户基于People这一分组下维护。
  • 搜索属性：uid。
  • 绑定DN：此处填写 cn=admin,dc=eryajf,dc=net，表示绑定到根域上去。
  • 登陆：Admin，这个用户与zabbix管理账户重叠，但是要注意需要先在LDAP中创建此用户，并设置密码。
  • 用户密码：将上一步创建用户的密码写在这里，点击测试，如果没毛病，将会通过测试。

# 2，Gitlab。

默认情况下，Gitlab没有开启ldap的认证，这个功能需要通过配置文件来启用，所以在现有Gitlab中，往配置文件里边添加如下配置：

cat /etc/gitlab/gitlab.rb
external_url 'http://10.133.205.206'
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.163.com"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_user_name'] = 'Linuxlql@163.com'
gitlab_rails['smtp_password'] = "xxxxxxx"
gitlab_rails['smtp_domain'] = "smtp.163.com"
gitlab_rails['smtp_authentication'] = :plain
#gitlab_rails['smtp_authentication'] = "login"
#gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_enable_starttls_auto'] = false
gitlab_rails['gitlab_email_from'] = "Linuxlql@163.com"
user["git_user_email"] = "Linuxlql@163.com"
git_data_dir "/home/git"
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = {
'main' => {
  'label' => 'OpenLDAP', # 随便自定义
  'host' =>  '10.3.0.42',   # ldap的server地址
  'port' => 389,    # ldap端口
  'uid' => 'sn',    # 配置为cn或者sn都可以，但要注意用户名称将会以此处配置为依据
  'encryption' => 'plain',  # 加密
  'bind_dn' => 'cn=admin,dc=eryajf,dc=net', # 管理员账号
  'password' => 'eryajf@456',   # 管理员密码
  'active_directory' => false,
  'base' => 'ou=People,dc=eryajf,dc=net',   # 核心配置，表示从哪一层读取用户信息
  'allow_username_or_email_login' => true,  # 是否启用邮件作为用户名登陆
  'verify_certificates' => true,    #
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

配置添加之后，依旧像安装时候那样，重载一下配置：

gitlab-ctl reconfigure
1

重载过程如果不报错，可以使用如下命令验证功能是否可用：

$ gitlab-rake gitlab:ldap:check
Checking LDAP ...
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
    DN: uid=test01,ou=people,dc=eryajf,dc=net    cn: ceshi
    DN: uid=test02,ou=people,dc=eryajf,dc=net    cn: test02
    DN: uid=test03,ou=people,dc=eryajf,dc=net    cn: test03
    DN: uid=admin,ou=people,dc=eryajf,dc=net     cn: Admin
    DN: uid=liql,ou=people,dc=eryajf,dc=net  cn: liql
Checking LDAP ... Finished
1
2
3
4
5
6
7
8
9
10
11

可以看到会刷出来当前所有的用户，此时配置就已经完成了，再次访问Gitlab，发现已经多了一个ldap登陆的选项。

image-20191024192805089

使用ldap用户名密码进行登陆即可，此时登陆进去是没有任何项目的权限，如果需要某权限，可以对用户进行组或者单项目的授权。

# 3，Jenkins

以上两种应用，都是基于最外层的用户进行管理的，并没有再细化分组，这种配置方式，是有其原因的，因为两者都是在默认登陆之后，用户无任何权限，需要通过管理员重新授权，从而获得相应的权限。

而Jenkins就不太一样了，Jenkins启用了ldap登陆之后，默认是登录用户就是管理员权限，尽管我们还可以通过更细化权限划分的插件来实现管控，但是这仍然让人觉得不那么优雅。

因此，在Jenkins这里，打算采用基于应用分组的方式进行配置。

配置之前，首先创建用户以及应用组，那么授权的时候，直接针对应用组授权即可。

创建普通用户：

  • 在People之下点击创建新条目
  • 模板选择默认
  • ObjectClasses选择inetOrgPerson，然后点击继续
  • 从上而下填写，RDN选择 User Name(uid)
  • 然后开始正式的人员信息填写
    • cn：zhangs
    • sn：zhangs
    • displayName：张三
    • 电子邮件：zhangs@qq.com
    • ou：People
    • 密码：123456
    • User Name：zhangs

然后点击创建，提交之后，一个普通用户就创建成功了。一般情况下，应用直接通过这一层来管理用户即可。

但是有些情况下，再另外拉出来一个分组，从软件的角度来分组，会更好一些。

创建一个应用组：

  • 在Group之下创建新条目
  • 模板选择默认
  • ObjectClasses选择groupOfNames，然后点击继续
  • 从上而下填写，RDN选择 cn(cn)
  • 然后开始填写组信息
    • cn：jenkins
    • member：点击后边的搜索框，选择将要包含的用户

然后点击创建，提交之后，就创建了一个jenkins组，配置ldap的时候，可以基于这个组来进行管理。

创建完成后的架构模式如下：

image-20191024210149443

可以看到，此时在Jenkins这个组里边，加入了三个用户，实际生产当中，原有用户应该已经存在，此时可以新增群组，然后将需要访问Jenkins应用的用户，加入进来，而没有加入这个组的用户，将无法访问。

下边进入正式配置，新版本的Jenkins已经默认集成了ldap，因此不需要额外安装插件，直接点击系统管理—>Configure Global Security，按照下边的内容，进行配置即可。

image-20191024210039994

配置完成，下边会有一个test，此时可以用其中一个账号密码进行测试，看到如下输出，则说明配置成功：

image-20191024210612711

保存之后，就可以通过ldap当中，Jenkins组内的用户名密码进行登陆了，这里只是解决了用户能够登陆Jenkins的问题，具体Jenkins中详细的用户权限分配，可以参考这篇文章进行配置 (opens new window)。

# 4，jumpserver

直接进入到jumpserver的系统设置里边，如下内容，进行配置，几项工具配置下来，基本上都熟悉了各个配置的概念了。

image-20191025163733208

配置完毕，可以点击测试连接，会看到导入几个用户的提示，然后点击提交配置，提交之后，可以点击一键导入，将对应用户导入进来：

image-20191025163956397

然后点击导入，即可将ldap中的用户导入到jumpserver中了。

# 5，harbor

常规来讲，harbor的认证，也像zabbix那样，只取用ldap最外层即可，也就是People下的所有人，都可以登录harbor，然后再针对不同的项目，对不同的用户进行授权即可。

这种配置比较简单，如下图所示：

image-20191029135235857

配置完成之后，可以点击一下测试看看效果，如果成功，则可以保存启用。

当然，如果人员数量很大，也可以走按组分配的方向，可以基于如上配置进行：

image-20191029140020957

同样，先测试是否可用，成功之后点击保存即可。保存之后，可以用其中一个用户进行登陆验证，可以在用户设置里边看到来自于LDAP。

image-20191029140226307

# 6，NGINX

# 1，基于全员的认证

NGINX基于ldap的认证，一旦出手，谁与争锋，日常业务当中，有太多页面内容，通过NGINX代理，有时需要添加认证以提高安全，使用NGINX的密码策略，又极不方便，容易出现一个账号多人使用的情况，而今接入到ldap，所有权限回归到ldap中，简直不要太优雅。

NGINX基于ldap的认证需要 nginx-auth-ldap模块儿，可以在原有已经在用的NGINX中，添加进去，或者直接全新的NGINX进行配置。

cd /opt
git clone https://github.com/nginxinc/nginx-ldap-auth
1
2

然后编译安装NGINX：

tar xf nginx-1.14.0.tar.gz
yum -y install zlib zlib-devel openssl openssl-devel pcre pcre-devel libxslt-devel
./configure --prefix=/usr/local/nginx --with-http_stub_status_module --with-http_ssl_module --with-http_v2_module --with-http_realip_module --add-module=/opt/nginx-auth-ldap
make && make install
1
2
3
4

然后进入正式配置：

$cat /usr/local/nginx/conf/nginx.conf
worker_processes  1;
events {
    worker_connections  1024;
}
http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    log_format json escape=json '{ "remote_addr": "$remote_addr",'
                           '"@timestamp":"$time_iso8601",'
                           '"request_uri": "$request_uri",'
                           '"verb": "$request_method",'
                           '"httpversion": "$server_protocol",'
                           '"response": "$status", '
                           '"body_bytes_sent": "$body_bytes_sent", '
                           '"referrer": "$http_referer", '
                           '"user_agent": "$http_user_agent", '
                           '"server_name": "$host",'
                           '"request_time": "$request_time",'
                           '"upstream_response_time": "$upstream_response_time",'
                           '"realpath_root": "$realpath_root",'
                           '"cookie": "$http_cookie",'
                           '"request_body": "$request_body",'
                           '"nginx_version": "$nginx_version",'
                           '"scheme": "$scheme"}';
    access_log /data/log/tmp.log json;
    error_log /data/log/error.log;
    ldap_server test {
    url ldap://10.3.0.42:389/DC=eryajf,DC=net?cn?sub?(objectClass=person);
    binddn "cn=admin,dc=eryajf,dc=net";
    binddn_passwd 123465;
        require valid_user;
    }
    ldap_server test_ldap1 {
        url "ldap://10.3.0.42:389/DC=eryajf,DC=net?uid?sub?(&(objectClass=organizationalPerson))";
        binddn "cn=admin,dc=eryajf,dc=net";
        binddn_passwd "123456";
        require valid_user;
        #group_attribute People;
        #group_attribute_is_dn on;
    #require group "cn=jenkins,ou=Group,dc=eryajf,dc=net";
    }
    server {
        listen       80;
        server_name  localhost;
        location / {
            auth_ldap "Forbidden";
            auth_ldap_servers test_ldap1;
            root   /usr/share/nginx/html;
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54

说明：最开始我使用的 test的配置，对于许多地方并没有过于在意，但是在请求的时候，总是进入死循环，输入用户名密码之后又跳入到了让输入用户名密码的界面，然后错误日志里边打印了一条：[error] 11539#0: *388 http_auth_ldap: Could not find user DN,，然后在官方issue中，看到一个不错的解答：https://github.com/kvspb/nginx-auth-ldap/issues/133

最后根据回答里边说明的，结合自己配置的实际情况，使用了 test_ldap1这个server，整体验证通过。

Oct-30-2019 17-18-38

然后就可以利用这种思路，给很多web界面套上这种管理方案了。

# 2，基于特定组的认证

以上配置用于验证用户层级的权限，也就是配置之后，所有的用户都可以访问对应的域名，这样似乎仍然有一丢丢不理想，对于一些重要的域名而言，显得权限放开的过宽。于是我想到通过组来进行权限的控制，这个配置的成型，同样也是经历千辛万苦各方验证而来，网上真正找到可用的，并不多，因此能看到这个地方的朋友，绝对是有缘了。

这个配置如下：

ldap_server test_ldap1 {
    url "ldap://10.3.0.42:389/DC=eryajf,DC=net?uid?sub?(&(objectClass=organizationalPerson))";
    binddn "cn=admin,dc=eryajf,dc=net";
    binddn_passwd "eryajf@456";
    group_attribute member;
    group_attribute_is_dn on;
    require group "cn=jenkins,ou=Group,dc=eryajf,dc=net";
}
server {
    listen       80;
    server_name  localhost;
    location / {
        auth_ldap "Forbidden";
        auth_ldap_servers test_ldap1;
        root   /usr/share/nginx/html;
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

这样就把权限控制在 jenkins这个组内了，其他人访问的时候，是被拒绝的。

如果你当前使用的是openresty，那么可以参考这篇文章进行模块的添加 (opens new window)。

# 7，Apollo

Apollo在安装配置完毕后，用户管理这块儿也可以接入到ldap当中，官方文档中给出了好几种方案，这里选取基于组进行过滤认证的方案。

需要在 /data/apollo/apollo-portal/config目录下添加如下配置文件：

spring:
  ldap:
    base: "dc=eryajf,dc=net"
    username: "cn=admin,dc=eryajf,dc=net" # 配置管理员账号，用于搜索、匹配用户
    password: "eryajf@456"
    searchFilter: "(uid={0})"  # 用户过滤器，登录的时候用这个过滤器来搜索用户
    urls:
    - "ldap://openldap.eryajf.net:389"

ldap:
  mapping: # 配置 ldap 属性
    objectClass: "inetOrgPerson" # ldap 用户 objectClass 配置
    loginId: "uid" # ldap 用户惟一 id，用来作为登录的 id
    rdnKey: "uid" # ldap rdn key
    userDisplayName: "cn" # ldap 用户名，用来作为显示名
    email: "mail" # ldap 邮箱属性
  group: # 启用group search，启用后只有特定group的用户可以登录apollo
    objectClass: "posixGroup"  # 配置groupClassName
    groupBase: "ou=groups" # group search base
    groupSearch: "(&(cn=apollo))" # group filter
    groupMembership: "member" # group memberShip eg. member or memberUid
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

然后在启动文件 /data/apollo/apollo-portal/scripts/startup.sh 中添加如下声明：

export JAVA_OPTS="$JAVA_OPTS -Dspring.profiles.active=github,ldap"
1

接着重启服务即可。

微信 支付宝
#ldap#zabbix#jenkins#gitlab#jumpserver#nginx#harbor
上次更新: 2022/08/19, 09:49:20

← 通过命令行管理用户分组备份等工作→

最近更新
01
记录2022年购买过的电子产品
05-26
02
一次因为Mac系统升级引发的ssh无法免密登陆的问题
05-26
03
学习周刊-总第108期-2023年第21周
05-26
更多文章>
Theme by Vdoing | Copyright © 2017-2023 | 点击查看十年之约 | 浙ICP备18057030号