syxdevcode博客

发表于 更新于 分类于

方法一

1
2
3
4
5
#显示所有的容器，过滤出Exited状态的容器，取出这些容器的ID，
sudo docker ps -a|grep Exited|awk '{print $1}'

#查询所有的容器，过滤出Exited状态的容器，列出容器ID，删除这些容器
sudo docker rm `docker ps -a|grep Exited|awk '{print $1}'`

方法二

1
2
#删除所有未运行的容器（已经运行的删除不了，未运行的就一起被删除了）
sudo docker rm $(sudo docker ps -a -q)

方法三

1
2
#根据容器的状态，删除Exited状态的容器
sudo docker rm $(sudo docker ps -qf status=exited)

方法四

1
2
#Docker 1.13版本以后，可以使用 docker containers prune 命令，删除孤立的容器。
sudo docker container prune
1
2
#删除所有镜像
sudo docker rmi $(docker images -q)

参考：

如何批量删除Docker中已停止的容器？-可以有多种方式

发表于 更新于 分类于

SASL认证简介

SASL：简单认证和安全层

SASL是一种用来扩充C/S模式验证能力的机制认证机制，全称 Simple Authentication and Security Layer。

当你设定sasl时，你必须决定两件事；一是用于交换“标识信 息”（或称身份证书）的验证机制；一是决定标识信息存储方法的验证架构。

sasl验证机制规范client与server之间的应答过程以及传输内容的编码方法，sasl验证架构决定服务器本身如何存储客户端的身份证书以及如何核验客户端提供的密码。

如果客户端能成功通过验证，服务器端就能确定用户的身份， 并借此决定用户具有怎样的权限。

比较常用的机制plain：plain是最简单的机制，但同时也是最危险的机制，因为身份证书（登录名称与密码）是以base64字符串格式通过网络，没有任何加密保护措施。因此，使用plain机制时，可能会想要结合tls。

参考：

SASL - 简单认证和安全层

阅读全文 »

发表于 更新于 分类于

自签名证书

参考：OpenSSL生成CA，二级CA，服务器证书

Kes配置文件

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
address: 0.0.0.0:7373 # Listen on all network interfaces on port 7373

admin:
  identity: disabled  # We disable the admin identity since we don't need it in this guide 
   
tls:
  #key: /opt/certs/agent/key/cakey.pem    # The KES server TLS private key
  #cert: /opt/certs/agent/key/cacert.crt       # The KES server TLS certificate  
  key: /opt/certs/25519/server.key    # The KES server TLS private key
  cert: /opt/certs/25519/server.crt       # The KES server TLS certificate
   
policy:
  my-app: 
    allow:
    - /v1/key/create/my-key*
    - /v1/key/generate/my-key*
    - /v1/key/decrypt/my-key*
    identities:
    - 0a3b5c174894c5b782889775a6a586c1dc8c9e03f8cf1b41be099a017ec25ec4 # Use the identity of your client.crt
   
keystore:
   vault:
     endpoint: https://127.0.0.1:8200
     version:  v1 # The K/V engine version - either "v1" or "v2".
     approle:
       id:     "a54e9ae2-a4e7-87bf-3fda-1fa30f65c3c5" # Your AppRole ID
       secret: "47ef5ebb-ebef-0ae1-001a-80dc74c8c638" # Your AppRole Secret
       retry:  15s
     status:
       ping: 10s
     tls:
       ca: /opt/certs/vault/vault.crt # Manually trust the vault certificate since we use self-signed certificates

-k 跳过证书校验。

1
kes key dek my-key-1 -k

参考：

Hashicorp Vault Keystore

发表于 更新于 分类于

查看 openssl 版本和配置文件位置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
$ openssl version -a
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
built on: Mon Jul  4 11:20:23 2022 UTC
platform: debian-amd64
options:  bn(64,64)
OPENSSLDIR: "/usr/lib/ssl" # 所在目录
ENGINESDIR: "/usr/lib/x86_64-linux-gnu/engines-3"
MODULESDIR: "/usr/lib/x86_64-linux-gnu/ossl-modules"
$ ls /usr/lib/ssl # 查看目录
certs  misc  openssl.cnf  private
$ cat /usr/lib/ssl/openssl.cnf # 查看配置文件

# openssl证书版本
openssl ciphers -v | awk '{print $2}' | sort | uniq
openssl s_client -help 2>&1  > /dev/null | egrep "\-(ssl|tls)[^a-z]"

证书认证相关

1. https 单项认证：

server: server.crt + server.key
client: server_ca.crt

2. https 双向认证：

server: server.crt + server.key + client_ca.crt
client: server_ca.crt + client.crt + client.key

在使用 CA 证书进行签署证书时加入-extfile和-extensions选项，具体命令如下：

1
2
openssl x509 -req  -days 365 -sha256 -extfile openssl.cnf -extensions v3_req
 -in server.csr -signkey server.key -out server.crt

证书详情信息：

1
2
3
4
5
6
7
8
9
10
11
Version: 版本号
Serial Number: 证书序列号
Signature Algorithm: 签名算法
Issuer: 签发者(签发证书的CA实体)
Subject: 证书主体(证书持有者实体)
Validity: 有效期
    Not Before: 开始生效时间
    Not After: 证书失效时间
Subject Public Key Info: 主体公钥信息
    Public Key Algorithm: 证书主题持有的公钥密钥算法
    RSA Public-Key: 具体的公钥数据

一般证书的签发流程是：

申请者把自己的申请做成证书申请文件 csr(csr 中放入了申请者的公钥以及申请者的信息)
然后把 csr 发送给签发者 CA 进行证书签发，签发过程就是 CA 用自己的私钥给 csr 生成签名，然后制作为证书文件(.crt 或.pem)

nginx 判定证书的时候，是根据证书中的两个字段：Issuer 和 Subject
如果 Issuer == Subject 那么 nginx 就会认为这是一个自签名的根证书
如果 Issuer != Subject 那么 nginx 就会认为这不是一个自签名的证书，验证时需要带上签发这个证书的根证书

正式使用时，subject 中的 CN 字段需要填写使用者的域名，也就是 nginx 所在主机的域名。

证书生成

流程：自签 CA，由自签 CA 签发二级 CA，最后由二级 CA 签发网站证书。

openssl 参数参考：

1
2
3
-extensions v3_req 指定 X.509 v3版本
-extensions v3_ca 生成CA扩展名
-extfile /tmp/openssl.conf 指定特殊的配置文件
阅读全文 »

发表于 更新于 分类于

1.概述

在本文中，我们将探索Hashicorp的Vault - 一种用于在现代应用程序体系结构中安全地管理机密信息的流行工具。

我们将讨论的主要议题包括：

  • Vault试图解决什么问题
  • Vault的架构和主要概念
  • 设置一个简单的测试环境
  • 使用命令行工具与Vault交互

2.机密信息问题

在深入了解Vault之前，让我们试着了解它试图解决的问题：机密信息管理。

大多数应用程序需要访问机密数据才能正常工作。例如，电子商务应用程序可以在某处配置用户名/密码以便连接到其数据库。它还可能需要API密钥才能与其他服务提供商集成，例如支付网关，物流和其他业务合作伙伴。

数据库凭证和API密钥就是我们需要以安全的方式存储和提供给我们的应用程序的机密信息。

一个简单的解决方案是将这些信息存储在配置文件中，并在启动时读取它们。但是这种方法的问题显而易见：有权访问此文件的人共享我们的应用程序具有的数据库权限 - 通常可以完全访问所有存储的数据。

我们可以尝试通过加密这些文件来使事情变得更加困难。但是，这种方法在整体安全性方面不会增加太多。主要是因为我们的应用程序必须能够访问主密钥。当以这种方式使用时，加密仅是一种“错误”的安全感。

现代应用程序和云环境往往会增加一些额外的复杂性：分布式服务，多个数据库，消息传递系统等等，所有敏感信息都在各处传播，从而增加了安全漏洞的风险。

阅读全文 »

发表于 更新于 分类于

例如：

配置 upstream 的 location 代码：注意添加了 ~*

1
2
3
4
5
6
#代理后端接口
location ~* /api/ {
    proxy_pass   http://apicluster;   #转发请求的地址
    rewrite      ^/api/(.*)$ /$1 break;
    include      /etc/nginx/nginxconfig.io/proxy.conf;
}

单节点 location 代码：

1
2
3
4
5
6
#代理后端接口
location /api/ {
    proxy_pass https://10.10.0.106:8082;   #转发请求的地址
    rewrite ^/api/(.*)$ /$1 break;
    include      /etc/nginx/nginxconfig.io/proxy.conf;
}
阅读全文 »

发表于 更新于 分类于

location 介绍

location是Nginx中的块级指令(block directive)，location指令的功能是用来匹配不同的url请求，进而对请求做不同的处理和响应

location有两种匹配规则：

  • 1, 匹配URL类型，有四种参数可选，当然也可以不带参数。
1
location [ = | ~ | ~* | ^~ ] uri { … }
  • 2, 命名location，用@标识，类似于定于goto语句块。
1
location @name { … }
阅读全文 »

发表于 更新于 分类于

参数简介

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
# max_conns 最大连接数
upstream tomcats {
    server 10.10.0.103:8080 max_conns=20000;
    server 10.10.0.104:8080 max_conns=20000;
    server 10.10.0.105:8080 max_conns=20000;
}

# slow_start=60s  60s 之后该主机开始提供服务
# slow_start参数不能使用在hash radom load balaning中
# 如果在upstram中之有一台server则该参数无效
upstream tomcats {
    server 10.10.0.103:8080 weight=6 slow_start=60s;
    server 10.10.0.104:8080 weight=2;
    server 10.10.0.105:8080 weight=2;
}

# down 表示该主机不可用
upstream tomcats {
    server 10.10.0.103:8080 weight=6;
    server 10.10.0.104:8080 down;
}

# backup 表示当前服务器节点是备用机，之有在其他的所有服务都宕机以后，自己才会加入到集群当中
# backup参数不能使用在hash radom load balaning中
upstream tomcats {
    server 10.10.0.103:8080 backup;
    server 10.10.0.104:8080 weight=1;
    server 10.10.0.105:8080 weight=1;
}
阅读全文 »

发表于 更新于 分类于

单节点编排

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
version: "3"
services:
  minio:
    restart: always
    image: minio/minio
    container_name: minio
    ports:
      - "9100:9000" # api 端口
      - "9190:9090" # 控制台端口
    networks:
      - net0
    volumes:
      - /opt/minio/data:/data
    privileged: true
    environment:      
      MINIO_ACCESS_KEY: admin    #管理后台用户名
      MINIO_SECRET_KEY: admin123 #管理后台密码，最小8个字符
    command: server --console-address ':9090' /data  #指定容器中的目录 /data
networks:
  net0:

执行：

1
2
3
4
5
# 启动
docker-compose up -d

# 移除
docker-compose down -v
阅读全文 »
0%