from: IBM Bash 测试和比较函数
Bash shell 在当今的许多 Linux® 和 UNIX® 系统上都可使用，是 Linux 上常见的默认 shell。Bash 包含强大的编程功能，其中包括丰富的可测试文件类型和属性的函数，以及在多数编程语言中可以使用的算术和字符串比较函数。理解不同的测试并认识到 shell 还能把一些操作符解释成 shell 元字符，是成为高级 shell 用户的重要一步。这篇文章摘自 developerWorks 教程 LPI 102 考试准备，主题 109: Shell、脚本、编程和编译，介绍了如何理解和使用 Bash shell 的测试和比较操作。
这个技巧解释了 shell 测试和比较函数，演示了如何向 shell 添加编程功能。您可能已经看到过使用 && 和 || 操作符的简单 shell 逻辑，它允许您根据前一条命令的退出状态（正确退出或伴随错误退出）而执行后一条命令。在这个技巧中，将看到如何把这些基本的技术扩展成更复杂的 shell 编程。
在任何一种编程语言中，学习了如何给变量分配值和传递参数之后，都需要测试这些值和参数。在 shell 中，测试会设置返回的状态，这与其他命令执行的功能相同。实际上，test 是个内置命令！
内置命令 test 根据表达式expr 求值的结果返回 0（真）或 1（假）。也可以使用方括号：test expr 和 [ expr ] 是等价的。 可以用 $? 检查返回值；可以使用 && 和 || 操作返回值；也可以用本技巧后面介绍的各种条件结构测试返回值。
清单 1. 一些简单测试1
2
3
4
5
6[ian@pinguino ~]$ test 3 -gt 4 && echo True || echo false
false
[ian@pinguino ~]$ [ "abc" != "def" ];echo $?
0
[ian@pinguino ~]$ test -d "$HOME" ;echo $?
0
在清单 1 的第一个示例中，-gt 操作符对两个字符值之间执行算术比较。在第二个示例中，用 [ ] 的形式比较两个字符串不相等。在最后一个示例中，测试 HOME 变量的值，用单目操作符 -d 检查它是不是目录。
可以用 -eq、 -ne、-lt、 -le、 -gt 或 -ge 比较算术值，它们分别表示等于、不等于、小于、小于等于、大于、大于等于。
可以分别用操作符 =、 !=、< 和 > 比较字符串是否相等、不相等或者第一个字符串的排序在第二个字符串的前面或后面。单目操作符 -z 测试 null 字符串，如果字符串非空 -n 返回 True（或者根本没有操作符）。
说明：shell 也用 < 和 > 操作符进行重定向，所以必须用 \< 或 > 加以转义。清单 2 显示了字符串测试的更多示例。检查它们是否如您预期的一样。
清单 2. 一些字符串测试1
2
3
4
5
6
7
8
9
10
11
12[ian@pinguino ~]$ test "abc" = "def" ;echo $?
1
[ian@pinguino ~]$ [ "abc" != "def" ];echo $?
0
[ian@pinguino ~]$ [ "abc" \< "def" ];echo $?
0
[ian@pinguino ~]$ [ "abc" \> "def" ];echo $?
1
[ian@pinguino ~]$ [ "abc" \<"abc" ];echo $?
1
[ian@pinguino ~]$ [ "abc" \> "abc" ];echo $?
1
表 1 显示了一些更常见的文件测试。如果被测试的文件存在，而且有指定的特征，则结果为 True。
表 1. 一些常见的文件测试
| 操作符 | 特征 |
|---|---|
| -d | 目录 |
| -e | 存在（也可以用 -a |
| -f | 普通文件｜ |
| -h | 符号连接 |
| -p | 命名管道 |
| -r | 可读 |
| -s | 非空 |
| -S | 套接字 |
| -W | 可写 |
| -N | 从上次读取之后已经做过修改 |
除了上面的单目测试，还可以使用表 2 所示的双目操作符比较两个文件：
表 2. 测试一对文件
| 操作符 | 为 True 的情况 |
|---|---|
| -ot | 测试file1 是否比 file2 更旧。 |
| -ef | 测试file1 是否比 file2的硬连接。 |
| -nt | 测试file1 是否比file2 更新。修改日期将用于这次和下次比较。 |
其他一些测试可以用来测试文件许可之类的内容。请参阅 bash 手册获得更多细节或使用 help test 查看内置测试的简要信息。也可以用 help 命令了解其他内置命令。
-o 操作符允许测试利用 set -o 选项 设置的各种 shell 选项，如果设置了该选项，则返回 True (0)，否则返回 False (1)，如清单 3 所示。
清单 3. 测试 shell 选项1
2
3
4
5
6[ian@pinguino ~]$ set +o nounset
[ian@pinguino ~]$ [ -o nounset ];echo $?
1
[ian@pinguino ~]$ set -u
[ian@pinguino ~]$ test -o nounset; echo $?
0
最后，-a 和 -o 选项允许使用逻辑运算符 AND 和 OR 将表达式组合在一起。单目操作符 ! 可以使测试的意义相反。可以用括号把表达式分组，覆盖默认的优先级。请记住 shell 通常要在子 shell 中运行括号中的表达式，所以需要用 ( 和 ) 转义括号，或者把这些操作符括在单引号或双引号内。清单 4 演示了摩根法则在表达式上的应用。
清单 4. 组合和分组测试1
2
3
4
5
6[ian@pinguino ~]$ test "a" != "$HOME" -a 3 -ge 4 ; echo $?
1
[ian@pinguino ~]$ [ ! \( "a" = "$HOME" -o 3 -lt 4 \) ]; echo $?
1
[ian@pinguino ~]$ [ ! \( "a" = "$HOME" -o '(' 3 -lt 4 ')' ")" ]; echo $?
1
test 命令非常强大，但是很难满足其转义需求以及字符串和算术比较之间的区别。幸运的是，bash 提供了其他两种测试方式，这两种方式对熟悉 C、C++ 或 Java® 语法的人来说会更自然些。
(( ))复合命令 计算算术表达式，如果表达式求值为 0，则设置退出状态为 1；如果求值为非 0 值，则设置为 0。不需要对 (( 和 )) 之间的操作符转义。算术只对整数进行。除 0 会产生错误，但不会产生溢出。可以执行 C 语言中常见的算术、逻辑和位操作。 let 命令也能执行一个或多个算术表达式。它通常用来为算术变量分配值。
清单 5. 分配和测试算术表达式1
2
3
4
5
6[ian@pinguino ~]$ let x=2 y=2**3 z=y*3;echo $? $x $y $z
0 2 8 24
[ian@pinguino ~]$ (( w=(y/x) + ( (~ ++x) & 0x0f ) )); echo $? $x $y $w
0 3 8 16
[ian@pinguino ~]$ (( w=(y/x) + ( (~ ++x) & 0x0f ) )); echo $? $x $y $w
0 4 8 13
同使用 (( )) 一样，利用复合命令 [[ ]] 可以对文件名和字符串使用更自然的语法。可以用括号和逻辑操作符把 test 命令支持的测试组合起来。
清单 6. 使用 [[ 复合命令1
2
3[ian@pinguino ~]$ [[ ( -d "$HOME" ) && ( -w "$HOME" ) ]] &&
> echo "home is a writable directory"
home is a writable directory
在使用 = 或 != 操作符时，复合命令 [[ 还能在字符串上进行模式匹配。匹配的方式就像清单 7 所示的通配符匹配。
清单 7. 用 [[ 进行通配符测试1
2
3
4
5
6[ian@pinguino ~]$ [[ "abc def .d,x--" == a[abc]*\ ?d* ]]; echo $?
0
[ian@pinguino ~]$ [[ "abc def c" == a[abc]*\ ?d* ]]; echo $?
1
[ian@pinguino ~]$ [[ "abc def d,x" == a[abc]*\ ?d* ]]; echo $?
1
甚至还可以在 [[ 复合命令内执行算术测试，但是千万要小心。除非在 (( 复合命令内，否则 < 和 > 操作符会把操作数当成字符串比较并在当前排序序列中测试它们的顺序。清单 8 用一些示例演示了这一点。
清单 8. 用 [[ 包含算术测试1
2
3
4
5
6
7
8
9
10[ian@pinguino ~]$ [[ "abc def d,x" == a[abc]*\ ?d* || (( 3 > 2 )) ]]; echo $?
0
[ian@pinguino ~]$ [[ "abc def d,x" == a[abc]*\ ?d* || 3 -gt 2 ]]; echo $?
0
[ian@pinguino ~]$ [[ "abc def d,x" == a[abc]*\ ?d* || 3 > 2 ]]; echo $?
0
[ian@pinguino ~]$ [[ "abc def d,x" == a[abc]*\ ?d* || a > 2 ]]; echo $?
0
[ian@pinguino ~]$ [[ "abc def d,x" == a[abc]*\ ?d* || a -gt 2 ]]; echo $?
-bash: a: unbound variable
虽然使用以上的测试和 &&、 || 控制操作符能实现许多编程，但 bash 还包含了更熟悉的 “if, then, else” 和 case 结构。学习完这些之后，将学习循环结构，这样您的工具箱将真正得到扩展。
bash 的 if 命令是个复合命令，它测试一个测试或命令（$?）的返回值，并根据返回值为 True（0）或 False（不为 0）进行分支。虽然上面的测试只返回 0 或 1 值，但命令可能返回其他值。请参阅 LPI 102 考试准备，主题 109: Shell、脚本、编程和编译 教程学习这方面的更多内容。
Bash 中的 if 命令有一个 then 子句，子句中包含测试或命令返回 0 时要执行的命令列表，可以有一个或多个可选的 elif 子句，每个子句可执行附加的测试和一个 then 子句，子句中又带有相关的命令列表，最后是可选的 else 子句及命令列表，在前面的测试或 elif 子句中的所有测试都不为真的时候执行，最后使用 fi 标记表示该结构结束。
使用迄今为止学到的东西，现在能够构建简单的计算器来计算算术表达式，如清单 9 所示：
清单 9. 用 if、then、else 计算表达式1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24[ian@pinguino ~]$ function mycalc ()
{
local x
if [ $# -lt 1 ]; then
echo "This function evaluates arithmetic for you if you give it some"
elif (( $* )); then
let x="$*"
echo "$* = $x"
else
echo "$* = 0 or is not an arithmetic expression"
fi
}
[ian@pinguino ~]$ mycalc 3 + 4
3 + 4 = 7
[ian@pinguino ~]$ mycalc 3 + 4**3
3 + 4**3 = 67
[ian@pinguino ~]$ mycalc 3 + (4**3 /2)
-bash: syntax error near unexpected token `('
[ian@pinguino ~]$ mycalc 3 + "(4**3 /2)"
3 + (4**3 /2) = 35
[ian@pinguino ~]$ mycalc xyz
xyz = 0 or is not an arithmetic expression
[ian@pinguino ~]$ mycalc xyz + 3 + "(4**3 /2)" + abc
xyz + 3 + (4**3 /2) + abc = 35
这个计算器利用 local 语句将 x 声明为局部变量，只能在 mycalc 函数的范围内使用。let 函数具有几个可用的选项，可以执行与它密切关联的 declare 函数。请参考 bash 手册或使用 help let 获得更多信息。
如清单 9 所示，需要确保在表达式使用 shell 元字符 —— 例如(、)、*、> 和 < 时 —— 正确地对表达式转义。无论如何，现在有了一个非常方便的小计算器，可以像 shell 那样进行算术计算。
在清单 9 中可能注意到 else 子句和最后的两个示例。可以看到，把 xyz 传递给 mycalc 并没有错误，但计算结果为 0。这个函数还不够灵巧，不能区分最后使用的示例中的字符值，所以不能警告用户。可以使用字符串模式匹配测试（例如
[[ ! (“$“ == [a-zA-Z]* ]]
，或使用适合自己范围的形式）消除包含字母表字符的表达式，但是这会妨碍在输入中使用 16 进制标记，因为使用 16 进制标记时可能要用 0x0f 表示 15。实际上，shell 允许的基数最高为 64（使用 base#value 标记），所以可以在输入中加入 _ 和 @ 合法地使用任何字母表字符。8 进制和 16 进制使用常用的标记方式，开头为 0 表示八进制，开头为 0x 或 0X 表示 16 进制。清单 10 显示了一些示例。
清单 10. 用不同的基数进行计算1
2
3
4
5
6
7
8
9
10
11
12
13
14[ian@pinguino ~]$ mycalc 015
015 = 13
[ian@pinguino ~]$ mycalc 0xff
0xff = 255
[ian@pinguino ~]$ mycalc 29#37
29#37 = 94
[ian@pinguino ~]$ mycalc 64#1az
64#1az = 4771
[ian@pinguino ~]$ mycalc 64#1azA
64#1azA = 305380
[ian@pinguino ~]$ mycalc 64#1azA_@
64#1azA_@ = 1250840574
[ian@pinguino ~]$ mycalc 64#1az*64**3 + 64#A_@
64#1az*64**3 + 64#A_@ = 1250840574
对输入进行的额外处理超出了本技巧的范围，所以请小心使用这个计算器。
elif 语句非常方便。它允许简化缩进，从而有助于脚本编写。在清单 11 中可能会对 type 命令在 mycalc 函数中的输出感到惊讶。
清单 11. Type mycalc1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16[ian@pinguino ~]$ type mycalc
mycalc is a function
mycalc ()
{
local x;
if [ $# -lt 1 ]; then
echo "This function evaluates arithmetic for you if you give it some";
else
if (( $* )); then
let x="$*";
echo "$* = $x";
else
echo "$* = 0 or is not an arithmetic expression";
fi;
fi
}
当然，也可以只用 $(( 表达式 )) 和 echo 命令进行 shell 算术运算，如清单 12 所示。这样就不必学习关于函数或测试的任何内容，但是请注意 shell 不会解释元字符，例如 *，因此元字符不能在 (( 表达式 )) 或 [[ 表达式 ]] 中那样正常发挥作用。
清单 12. 在 shell 中用 echo 和 $(( )) 直接进行计算1
2[ian@pinguino ~]$ echo $((3 + (4**3 /2)))
35
在自己搭建的单点集群中，slaver虚机的IP发生变化时，在master上还总是能看到之前的结点信息。
下面的内容，解释了为什么失联的node不会被删掉。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
node是kubernetes集群中的工作节点，可以是虚拟机也可以是物理机。node节点上运行一些服务用来运行pod以及与master通信等。一个node上的服务包括docker运行时环境、kubelet、kube-proxy以及其它一些可选的add-ons。
node的状态包含如下几个方面的信息:1
2
3
4
5Addresses
Condition
Capacity
Info
Addresses
节点的地址信息由node的配置决定，包含如下三项:1
2
3HostName：同node内核决定的主机名，可以由kubelet的--hostname-override选项覆盖。
ExternalIP：外网访问IP。
InternalIP：内网IP，集群内部的私有地址。
Conditions描述所有处于RUNNING状态的节点信息。
| Node Condition | Description |
|---|---|
| OutOfDisk | True if there is insufficient free space on the node for adding new pods, otherwise False |
| Ready | True if the node is healthy and ready to accept pods, False if the node is not healthy and is not accepting pods, and Unknown if the node controller has not heard from the node in the last node-monitor-grace-period (default is 40 seconds) |
| MemoryPressure | True if pressure exists on the node memory – that is, if the node memory is low; otherwise False |
| PIDPressure | True if pressure exists on the processes – that is, if there are too many processes on the node; otherwise False |
| DiskPressure | True if pressure exists on the disk size – that is, if the disk capacity is low; otherwise False |
| NetworkUnavailable | True if the network for the node is not correctly configured, otherwise False |
| ConfigOK | True if the kubelet is correctly configured, otherwise False |
关键问题是以上这些信息是如何计算判定的呢？
Node的conditions用json对象表示，如以下应答表示健康的node：1
2
3
4
5
6"conditions": [
{
"type": "Ready",
"status": "True"
}
]
如果节点的Ready condition是“Unknown” 或者 “False”，kube-controller-manager则将这个节点标记为不可用状态。节点上所有的pod被Node Controller调度排除，默认的排除超时时间是５分钟。有时节点因为网络原因不可达，kubernetes的控制面无法与节点上的kubelet建立联系，删除pod的指令无法下发到kubelet上，则可能的情况是控制面一直试图联系失联节点直到通信恢复，在此期间在此失联节点上的pod一直持续运行。
在kubernetes１.５及以前版本中，node controller可能会强制从系统中删除不可达的pod。但是，在１.５及更高的版本中，node controller直到明确确认这些pod停止运行后才会将它们从系统记录中删除，也就是说node controller必需明确知道pod的状态如“Terminating” 或者 “Unknown”。对于永久失联的node，kubernetes无法确定这个node是暂时失联稍后恢复还是永久从集群中删除，在这种情况下需要管理员手动删除node对象，删除node会引发kubernetes删除节点上的所有pod，并且释放它们所占用的名称。
从1.8版本开始介绍了一种新的测试特性，就是自动创建taints表示conditions。要想打开这种特性，需要给API server，controller manager，scheduler传递一个开关： –feature-gates=…,TaintNodesByCondition=true。当TaintNodesByCondition被打开后，scheduler在调度时就会忽略掉节点的conditions，代之以查看节点的taints与pod的tolerations。
现在用户可以在旧的调度模式与新的调度模式，一种更灵活的调度模式之间作出选择。对于没有任何tolerations的pod使用旧的调度模式，但是，如果pod能够容忍在特定节点上被污染的话，就会被调度到那个特定节点上。
需要注意：node的condition被观测到taints被创建的时间跨度，通常小于１秒，因为这种时间延迟，有可能会轻微的增加pod被成功调度出去，但是kubelet却拒绝接收的情况。
描述节点的可用资源：CPU、内在以及其上可以调度的最大的pod数等。
节点常规信息，如内核版本、kubernetes版本，docker版本、操作系统名称等。这些信息由节点上的kubelet提供。
node不同于pod、service等kubernetes内部创建的对象，它是由外部创建。当在kubernetes内部创建node时，只是在kubernetes内部创建一个表示已经存在节点的对象。创建完以后kubernetes会检查节点是否可用，比如创建了如下节点:1
2
3
4
5
6
7
8
9
10{
"kind": "Node",
"apiVersion": "v1",
"metadata": {
"name": "10.240.79.157",
"labels": {
"name": "my-first-k8s-node"
}
}
}
kubernetes由提供的信息在内部创建一个代表节点的node对象，然后对节点执行可用性检查，如必需的服务是否在正常运行，是否具备运行pod的资格。如果不可用则不让这个节点参与任何集群活动。系统会保留不可用node并且持续监控它的状态，直到它可用为止，或者是用户明确删除创建的node对象。
目前，有三个组件会与kubernetes的node接口交互：node controller, kubelet, and kubectl。
Node controller是kubernetes控制面中的一个组件，负责管理node的方方面面。
在node的整个生命周期中，node controller充当多种角色，首先在node注册入集群时为它分配一个CIDR地址块（如果此特性打开的话）。
第二个是维护node controller内部的可用节点列表，并与低层的云供商的可用节点的列表保持一致。当运行在云环境中时，如果node controller检测到某个节点不健康，它就会向供应商询问节点虚拟机是否可用，如果不可用就从列表删除。
第三个是监控节点的健康状态。Node controller检测到node不可达时，负责将node状态中的NodeReady condition更新到ConditionUnknown，然后将node上的所有pod排除（如果节点不可达的时候超过40s（默认值），会被标记成ConditionUnknown，此时并没有发生排除pod的动作，系统试图重新联系不可达的node，如果恢复的话则node重新被标记成NodeReady。如果不可达的时间超过５分钟（默认值）才会采取排除步骤）。系统每隔–node-monitor-period设置的秒数检测一次节点的状态。
在kubernetes１.４中，改善了node controller处理集群中node数过多的逻辑。从1.4开始，node controller在决定是否排除pod之前，先检测一次集群中所有node的状态。
在多数情况下，node controller通过–node-eviction-rate的设定值限制了排除pod的速率,默认是0.1次每秒，意思是对于单个node，排除的速率小于10秒一次。
当node在一个可用的zone变得不健康时，node的排除行为会发生改变，也就是说排除行为并不是一成不变。Node controller检测在zone内不健康node的百分数，如果不健康node的比例低于–unhealthy-zone-threshold (default 0.55)，那么排除速率将会降低：如果集群规模小（node数小于或者等于–large-cluster-size-threshold，默认50），则排除行为终止，则否，排除速率将会降低到–secondary-node-eviction-rate（默认0.01）每秒。如此策略的主要原因主要是为在将一个可用的zone分区时提供一种过渡缓冲。如果你的集群没有跨多个云供应商的话，那么你只有一个可用的zone，就是整个集群。
将node分布在不同可用zone的主要原因是当一个zone整体不能用时，可以将workload切换到另一个可用的zone。所以当一个zone不可用时，kubernetes以正常速率排除。极端情况下，如果所有zone都不可用，那么kubernetes假定master之间的联通性出现了问题，停止一切排除行为直到master之间的联通性恢复。
从1.6版本开始，当pod不容忍taints时，node controller也负责排除运行在node上的NoExecute taints，这是一个测试特性，默认禁止。Node controller负责添加与node问题对应的taint，比如不可达。
从1.8版本开始，node controller能够被用来创建表示node conditions的taint，这是1.8版本的一个测试特性。
当node中kubelete的标志–register-node被设置成true时，kubelete尝试主动注册自已到系统中。这是一种被大多数distros使用的比较好的模式。本质是是由kubelete在系统中创建node对象而非用户手动。
自注册node的kubelet需要指定如下几个启动参数：
集群管理员可以手动创建、修改node对象，当然先要把node的自注册功能关掉，设置node的kubelete标志–register-node=false。
用户可以手动设置node标签、或者使node不可以被安排调度。
标签可以被node selectors用来聚合node从而控制调度，比如约束pod只能调度到符合条件的node上。
使node不可调度，可以阻止node授受新的调度任务，对已经存在的pod没有影响。这个特性很有用。使node不可调度可运行如下命令：
kubectl cordon $NODENAME
注意，使node不可调度，对DaemonSet类型的pod无效。
Node的capacity也是node对象的一部分。自注册节点在创建node对象时自动注册此部分内容。但是，如果是手动管理node对象的话，则也需要手动设置此部分内部。
Kubernetes scheduler在调度pod之前，首先要确保node上有足够运行pod的资源，它要确保node上运行的所有container占用的资源不能超过节点的 capacity。但是，默认情况下在统计node的资源占用情况时，只计算由kubelete启动的容器，其它进程占用的资源不在统计之内。
如果想明确检视非pod进程占用的资源的话，按如下模板在每个node节点上创建manifest类型的pod：1
2
3
4
5
6
7
8
9
10
11
12apiVersion: v1
kind: Pod
metadata:
name: resource-reserver
spec:
containers:
- name: sleep-forever
image: k8s.gcr.io/pause:0.8.0
resources:
requests:
cpu: 100m
memory: 100Mi
1 |
|
想理解认证，我们得从认证解决什么问题、防止什么问题的发生入手。
防止什么问题呢？是防止有人入侵你的集群，root你的机器后让我们集群依然安全吗？不是吧，root都到手了，那就为所欲为，防不胜防了。
其实网络安全本身就是为了解决在某些假设成立的条件下如何防范的问题。比如一个非常重要的假设就是两个节点或者ip之间的通讯网络是不可信任的，可能会被第三方窃取，也可能会被第三方篡改。就像我们上学时候给心仪的女孩传纸条，传送的过程可能会被别的同学偷看，甚至内容可能会从我喜欢你修改成我不喜欢你了。当然这种假设不是随便想出来的，而是从网络技术现状和实际发生的问题中发现、总结出来的。kubernetes的认证也是从这个问题出发来实现的。
为了解决上面说的问题，kubernetes并不需要自己想办法，毕竟是网络安全层面的问题，是每个服务都会遇到的问题，业内也有成熟的方案来解决。这里我们一起了解一下业内方案和相关的概念。
授权的概念就简单多了，就是什么人具有什么样的权限，一般通过角色作为纽带把他们组合在一起。也就是一个角色一边拥有多种权限，一边拥有多个人。这样就把人和权限建立了一个关系。
Kubernetes集群的所有操作基本上都是通过kube-apiserver这个组件进行的，它提供HTTP RESTful形式的API供集群内外客户端调用。需要注意的是：认证授权过程只存在HTTPS形式的API中。也就是说，如果客户端使用HTTP连接到kube-apiserver，那么是不会进行认证授权的。所以说，可以这么设置，在集群内部组件间通信使用HTTP，集群外部就使用HTTPS，这样既增加了安全性，也不至于太复杂。
对APIServer的访问要经过的三个步骤，前面两个是认证和授权，第三个是 Admission Control，它也能在一定程度上提高安全性，不过更多是资源管理方面的作用。
kubernetes提供了多种认证方式，比如客户端证书、静态token、静态密码文件、ServiceAccountTokens等等。你可以同时使用一种或多种认证方式。只要通过任何一个都被认作是认证通过。下面我们就认识几个常见的认证方式。
在Kubernetes1.6版本中新增角色访问控制机制（Role-Based Access，RBAC）让集群管理员可以针对特定使用者或服务账号的角色，进行更精确的资源访问控制。在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中，角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
目前 Kubernetes 中有一系列的鉴权机制，因为Kubernetes社区的投入和偏好，相对于其它鉴权机制而言，RBAC是更好的选择。具体RBAC是如何体现在kubernetes系统中的我们会在后面的部署中逐步的深入了解。
AdmissionControl - 准入控制本质上为一段准入代码，在对kubernetes api的请求过程中，顺序为：先经过认证 & 授权，然后执行准入操作，最后对目标对象进行操作。这个准入代码在api-server中，而且必须被编译到二进制文件中才能被执行。
在对集群进行请求时，每个准入控制代码都按照一定顺序执行。如果有一个准入控制拒绝了此次请求，那么整个请求的结果将会立即返回，并提示用户相应的error信息。
常用组件（控制代码）如下：
开始之前我们要先把基础版本的集群停掉，包括service，deployments，pods以及运行的所有kubernetes组件1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18#删除services
$ kubectl delete services nginx-service
#删除deployments
$ kubectl delete deploy kubernetes-bootcamp
$ kubectl delete deploy nginx-deployment
#停掉worker节点的服务
$ service kubelet stop && rm -fr /var/lib/kubelet/*
$ service kube-proxy stop && rm -fr /var/lib/kube-proxy/*
$ service kube-calico stop
#停掉master节点的服务
$ service kube-calico stop
$ service kube-scheduler stop
$ service kube-controller-manager stop
$ service kube-apiserver stop
$ service etcd stop && rm -fr /var/lib/etcd/*
跟基础环境搭建一样，我们需要生成kubernetes-with-ca的所有相关配置文件1
2
3
4
5$ cd ~/kubernetes-starter
#按照配置文件的提示编辑好配置
$ vi config.properties
#生成配置
$ ./gen-config.sh with-ca
cfssl是非常好用的CA工具，我们用它来生成证书和秘钥文件
安装过程比较简单，如下：1
2
3
4
5
6
7
8
9
10
11#下载
$ wget -q --show-progress --https-only --timestamping \
https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 \
https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
#修改为可执行权限
$ chmod +x cfssl_linux-amd64 cfssljson_linux-amd64
#移动到bin目录
$ mv cfssl_linux-amd64 /usr/local/bin/cfssl
$ mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
#验证
$ cfssl version
根证书是证书信任链的根，各个组件通讯的前提是有一份大家都信任的证书（根证书），每个人使用的证书都是由这个根证书签发的。1
2
3
4
5
6
7
8
9
10
11#所有证书相关的东西都放在这
$ mkdir -p /etc/kubernetes/ca
#准备生成证书的配置文件
$ cp ~/kubernetes-starter/target/ca/ca-config.json /etc/kubernetes/ca
$ cp ~/kubernetes-starter/target/ca/ca-csr.json /etc/kubernetes/ca
#生成证书和秘钥
$ cd /etc/kubernetes/ca
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
#生成完成后会有以下文件（我们最终想要的就是ca-key.pem和ca.pem，一个秘钥，一个证书）
$ ls
ca-config.json ca.csr ca-csr.json ca-key.pem ca.pem
etcd节点需要提供给其他服务访问，就要验证其他服务的身份，所以需要一个标识自己监听服务的server证书，当有多个etcd节点的时候也需要client证书与etcd集群其他节点交互，当然也可以client和server使用同一个证书因为它们本质上没有区别。1
2
3
4
5
6
7
8
9
10
11
12
13
14#etcd证书放在这
$ mkdir -p /etc/kubernetes/ca/etcd
#准备etcd证书配置
$ cp ~/kubernetes-starter/target/ca/etcd/etcd-csr.json /etc/kubernetes/ca/etcd/
$ cd /etc/kubernetes/ca/etcd/
#使用根证书(ca.pem)签发etcd证书
$ cfssl gencert \
-ca=/etc/kubernetes/ca/ca.pem \
-ca-key=/etc/kubernetes/ca/ca-key.pem \
-config=/etc/kubernetes/ca/ca-config.json \
-profile=kubernetes etcd-csr.json | cfssljson -bare etcd
#跟之前类似生成三个文件etcd.csr是个中间证书请求文件，我们最终要的是etcd-key.pem和etcd.pem
$ ls
etcd.csr etcd-csr.json etcd-key.pem etcd.pem
建议大家先比较一下增加认证的etcd配置与原有配置的区别，做到心中有数。
可以使用命令比较：1
2$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/etcd.service kubernetes-with-ca/master-node/etcd.service
更新etcd服务：1
2
3
4
5
6
7
8
9
10$ cp ~/kubernetes-starter/target/master-node/etcd.service /lib/systemd/system/
$ systemctl daemon-reload
$ service etcd start
#验证etcd服务（endpoints自行替换）
$ ETCDCTL_API=3 etcdctl \
--endpoints=https://192.168.1.102:2379 \
--cacert=/etc/kubernetes/ca/ca.pem \
--cert=/etc/kubernetes/ca/etcd/etcd.pem \
--key=/etc/kubernetes/ca/etcd/etcd-key.pem \
endpoint health
1 | #api-server证书放在这，api-server是核心，文件夹叫kubernetes吧，如果想叫apiserver也可以，不过相关的地方都需要修改哦 |
查看diff1
2$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/master-node/kube-apiserver.service kubernetes-with-ca/master-node/kube-apiserver.service
生成token认证文件1
2
3
4
5
6#生成随机token
$ head -c 16 /dev/urandom | od -An -t x | tr -d ' '
8afdf3c4eb7c74018452423c29433609
#按照固定格式写入token.csv，注意替换token内容
$ echo "8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,\"system:kubelet-bootstrap\"" > /etc/kubernetes/ca/kubernetes/token.csv
更新api-server服务1
2
3
4
5
6$ cp ~/kubernetes-starter/target/master-node/kube-apiserver.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-apiserver start
#检查日志
$ journalctl -f -u kube-apiserver
controller-manager一般与api-server在同一台机器上，所以可以使用非安全端口与api-server通讯，不需要生成证书和私钥。
查看diff1
2$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/kube-controller-manager.service kubernetes-with-ca/master-node/kube-controller-manager.service
更新controller-manager服务1
2
3
4
5
6$ cp ~/kubernetes-starter/target/master-node/kube-controller-manager.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-controller-manager start
#检查日志
$ journalctl -f -u kube-controller-manager
scheduler一般与apiserver在同一台机器上，所以可以使用非安全端口与apiserver通讯。不需要生成证书和私钥。
查看diff
比较会发现两个文件并没有区别，不需要改造1
2$ cd ~/kubernetes-starter/
$ vimdiff kubernetes-simple/master-node/kube-scheduler.service kubernetes-with-ca/master-node/kube-scheduler.service
启动服务1
2
3$ service kube-scheduler start
#检查日志
$ journalctl -f -u kube-scheduler
1 | #kubectl证书放在这，由于kubectl相当于系统管理员，我们使用admin命名 |
1 | #指定apiserver的地址和证书位置（ip自行修改） |
验证master节点1
2
3
4
5
6#可以使用刚配置好的kubectl查看一下组件状态
$ kubectl get componentstatus
NAME STATUS MESSAGE ERROR
scheduler Healthy ok
controller-manager Healthy ok
etcd-0 Healthy {"health": "true"}
后续可以看到calico证书用在四个地方：
1 | #calico证书放在这 |
查看diff1
2$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/all-node/kube-calico.service kubernetes-with-ca/all-node/kube-calico.service
通过diff会发现，calico多了几个认证相关的文件：
/etc/kubernetes/ca/ca.pem
/etc/kubernetes/ca/calico/calico.pem
/etc/kubernetes/ca/calico/calico-key.pem
由于calico服务是所有节点都需要启动的，大家需要把这几个文件拷贝到每台服务器上
更新calico服务1
2
3
4
5
6$ cp ~/kubernetes-starter/target/all-node/kube-calico.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kube-calico start
#验证calico（能看到其他节点的列表就对啦）
$ calicoctl node status
我们这里让kubelet使用引导token的方式认证，所以认证方式跟之前的组件不同，它的证书不是手动生成，而是由工作节点TLS BootStrap 向api-server请求，由主节点的controller-manager 自动签发。
引导token的方式要求客户端向api-server发起请求时告诉他你的用户名和token，并且这个用户是具有一个特定的角色：system:node-bootstrapper，所以需要先将 bootstrap token 文件中的 kubelet-bootstrap 用户赋予这个特定角色，然后 kubelet 才有权限发起创建认证请求。
在主节点执行下面命令1
2
3
4
5
6
7
8
9
10#可以通过下面命令查询clusterrole列表
$ kubectl -n kube-system get clusterrole
#可以回顾一下token文件的内容
$ cat /etc/kubernetes/ca/kubernetes/token.csv
8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
#创建角色绑定（将用户kubelet-bootstrap与角色system:node-bootstrapper绑定）
$ kubectl create clusterrolebinding kubelet-bootstrap \
--clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
这个配置是用来完成bootstrap token认证的，保存了像用户，token等重要的认证信息，这个文件可以借助kubectl命令生成：（也可以自己写配置）1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19#设置集群参数(注意替换ip)
$ kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ca/ca.pem \
--embed-certs=true \
--server=https://192.168.1.102:6443 \
--kubeconfig=bootstrap.kubeconfig
#设置客户端认证参数(注意替换token)
$ kubectl config set-credentials kubelet-bootstrap \
--token=8afdf3c4eb7c74018452423c29433609 \
--kubeconfig=bootstrap.kubeconfig
#设置上下文
$ kubectl config set-context default \
--cluster=kubernetes \
--user=kubelet-bootstrap \
--kubeconfig=bootstrap.kubeconfig
#选择上下文
$ kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
#将刚生成的文件移动到合适的位置
$ mv bootstrap.kubeconfig /etc/kubernetes/
查看diff1
2$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/10-calico.conf kubernetes-with-ca/worker-node/10-calico.conf
copy配置1
$ cp ~/kubernetes-starter/target/worker-node/10-calico.conf /etc/cni/net.d/
查看diff1
2$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/kubelet.service kubernetes-with-ca/worker-node/kubelet.service
更新服务1
2
3
4
5
6
7
8
9
10
11$ cp ~/kubernetes-starter/target/worker-node/kubelet.service /lib/systemd/system/
$ systemctl daemon-reload
$ service kubelet start
#启动kubelet之后到master节点允许worker加入(批准worker的tls证书请求)
#--------*在主节点执行*---------
$ kubectl get csr|grep 'Pending' | awk '{print $1}'| xargs kubectl certificate approve
#-----------------------------
#检查日志
$ journalctl -f -u kubelet
1 | #proxy证书放在这 |
1 | #设置集群参数（注意替换ip） |
查看diff1
2$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/worker-node/kube-proxy.service kubernetes-with-ca/worker-node/kube-proxy.service
经过diff你应该发现kube-proxy.service没有变化
启动服务1
2
3
4
5
6
7
8
9
10
11#如果之前的配置没有了，可以重新复制一份过去
$ cp ~/kubernetes-starter/target/worker-node/kube-proxy.service /lib/systemd/system/
$ systemctl daemon-reload
#安装依赖软件
$ apt install conntrack
#启动服务
$ service kube-proxy start
#查看日志
$ journalctl -f -u kube-proxy
kube-dns有些特别，因为它本身是运行在kubernetes集群中，以kubernetes应用的形式运行。所以它的认证授权方式跟之前的组件都不一样。它需要用到service account认证和RBAC授权。
service account认证：
每个service account都会自动生成自己的secret，用于包含一个ca，token和secret，用于跟api-server认证
RBAC授权：
权限、角色和角色绑定都是kubernetes自动创建好的。我们只需要创建一个叫做kube-dns的 ServiceAccount即可，官方现有的配置已经把它包含进去了。
我们在官方的基础上添加的变量，生成适合我们集群的配置。直接copy就可以啦1
2$ cd ~/kubernetes-starter
$ vimdiff kubernetes-simple/services/kube-dns.yaml kubernetes-with-ca/services/kube-dns.yaml
大家可以看到diff只有一处，新的配置没有设定api-server。不访问api-server，它是怎么知道每个服务的cluster ip和pod的endpoints的呢？这就是因为kubernetes在启动每个服务service的时候会以环境变量的方式把所有服务的ip，端口等信息注入进来。
1 | $ kubectl create -f ~/kubernetes-starter/target/services/kube-dns.yaml |
终于，安全版的kubernetes集群我们部署完成了。
下面我们使用新集群先温习一下之前学习过的命令，然后再认识一些新的命令，新的参数，新的功能。同样，具体内容请看视频教程吧~
在生成认证文件的时候，往往会用到， 网上很多有示例文件，一直不明白其中的CN，L，OU，什么的是什么意思。
在https://k8smeetup.github.io/docs/concepts/cluster-administration/certificates/上有如下介绍：1
2
3
4
5
6C = <country>
ST = <state>
L = <city>
O = <organization>
OU = <organization unit>
CN = <MASTER_IP>
$ cfssl gencert -initca ca-csr.json | cfssljson -bare ca
#生成完成后会有以下文件（我们最终想要的就是ca-key.pem和ca.pem，一个秘钥，一个证书）
$ ls
ca-config.json ca.csr ca-csr.json ca-key.pem ca.pem
上述命令中用到的ca-csr.json是：1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"ST": "Beijing",
"L": "XS",
"O": "k8s",
"OU": "System"
}
]
}
1 | Usage of gencert: |
1 | { |
1 | $ cfssl gencert \ |
我们最终要的是admin-key.pem和admin.pem
]]>更详细的介绍，请参照 ：https://coreos.com/os/docs/latest/generate-self-signed-certificates.html
1 | client certificate： 用于服务端认证客户端,例如etcdctl、etcd proxy、fleetctl、docker客户端 |
1 | mkdir /opt/ssl |
1 | { |
1 | { |
1 | cfssl gencert -initca ca-csr.json | cfssljson -bare ca - |
生成ca.pem、ca.csr、ca-key.pem(CA私钥,需妥善保管)
cfssl print-defaults csr > server-csr.json1
2
3
4
5
6
7
8
9...
"CN": "coreos1",
"hosts": [
"192.168.122.68",
"ext.example.com",
"coreos1.local",
"coreos1"
],
...
1 | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server-csr.json | cfssljson -bare server |
1 | cfssl print-defaults csr > admin-csr.json |
1 | ... |
1 | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client admin-csr.json | cfssljson -bare admin |
1 | cfssl print-defaults csr > kube-proxy-csr.json |
1 | ... |
1 | cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=peer kube-proxy-csr.json | cfssljson -bare kube-proxy |
针对etcd服务,每个etcd节点上按照上述方法生成相应的证书和私钥
校验生成的证书是否和配置相符1
2
3openssl x509 -in ca.pem -text -noout
openssl x509 -in server.pem -text -noout
openssl x509 -in client.pem -text -noout
1 | #生成随机token |
在apiserver服务启动时添加配置项KUBE_TOKEN_AUTH_FILE="--token-auth-file=/etc/kubernetes/pki/apiserver/token.csv"
1 | #指定apiserver的地址和证书位置（ip自行修改） |
我们这里让kubelet使用引导token的方式认证，所以认证方式跟之前的组件不同，它的证书不是手动生成，而是由工作节点TLS BootStrap 向api-server请求，由主节点的controller-manager 自动签发。
引导token的方式要求客户端向api-server发起请求时告诉他你的用户名和token，并且这个用户是具有一个特定的角色：system:node-bootstrapper，
所以需要先将 bootstrap token 文件中的 kubelet-bootstrap 用户赋予这个特定角色，然后 kubelet 才有权限发起创建认证请求。 在主节点执行下面命令1
2
3
4
5
6
7
8
9
10#可以通过下面命令查询clusterrole列表
$ kubectl -n kube-system get clusterrole
#可以回顾一下token文件的内容
$ cat /etc/kubernetes/ca/kubernetes/token.csv
8afdf3c4eb7c74018452423c29433609,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
#创建角色绑定（将用户kubelet-bootstrap与角色system:node-bootstrapper绑定）
$ kubectl create clusterrolebinding kubelet-bootstrap \
--clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
这个配置是用来完成bootstrap token认证的，保存了像用户，token等重要的认证信息，这个文件可以借助kubectl命令生成：（也可以自己写配置）1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17#设置集群参数(注意替换ip)
$ kubectl config set-cluster kubernetes \
--certificate-authority=/etc/kubernetes/ca/ca.pem \
--embed-certs=true \
--server=https://192.168.1.102:6443 \
--kubeconfig=bootstrap.kubeconfig
#设置客户端认证参数(注意替换token)
$ kubectl config set-credentials kubelet-bootstrap \
--token=8afdf3c4eb7c74018452423c29433609 \
--kubeconfig=bootstrap.kubeconfig
#设置上下文
$ kubectl config set-context default \
--cluster=kubernetes \
--user=kubelet-bootstrap \
--kubeconfig=bootstrap.kubeconfig
#选择上下文
$ kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
kubelet.service服务添加下面的参数：1
2
3
4KUBELET_POD_INFRA_CONTAINER_IMAGE="--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/imooc/pause-amd64:3.0"
KUBELET_EXPERIMENTAL_BOOTSTRAP_KUBECONFIG="--experimental-bootstrap-kubeconfig=/etc/kubernetes/bootstrap.kubeconfig"
KUBELET_CERT_DIR="--cert-dir=/etc/kubernetes/pki/apiserver"
KUBELET_HAIRPIN_MODE="--hairpin-mode hairpin-veth"
kube-proxy服务也需要生成证书。另外，需要生成kube-proxy.kubeconfig配置:1 | #设置集群参数（注意替换ip） |
之前没接触过证书加密的话,对证书相关的这些概念真是感觉挺棘手的,因为一下子来了一大堆新名词,看起来像是另一个领域的东西,而不是我们所熟悉的编程领域的那些东西,起码我个人感觉如此,且很长时间都没怎么搞懂.写这篇文章的目的就是为了理理清这些概念,搞清楚它们的含义及关联,还有一些基本操作.
SSL
SSL - Secure Sockets Layer,现在应该叫”TLS”,但由于习惯问题,我们还是叫”SSL”比较多.http协议默认情况下是不加密内容的,这样就很可能在内容传播的时候被别人监听到,对于安全性要求较高的场合,必须要加密,https就是带加密的http协议,而https的加密是基于SSL的,它执行的是一个比较下层的加密,也就是说,在加密前,你的服务器程序在干嘛,加密后也一样在干嘛,不用动,这个加密对用户和开发者来说都是透明的.More:[维基百科]
OpenSSL - 简单地说,OpenSSL是SSL的一个实现,SSL只是一种规范.理论上来说,SSL这种规范是安全的,目前的技术水平很难破解,但SSL的实现就可能有些漏洞,如著名的”心脏出血”.OpenSSL还提供了一大堆强大的工具软件,强大到90%我们都用不到.
证书标准
X.509 - 这是一种证书标准,主要定义了证书中应该包含哪些内容.其详情可以参考RFC5280,SSL使用的就是这种证书标准.
编码格式
同样的X.509证书,可能有不同的编码格式,目前有以下两种编码格式.
PEM - Privacy Enhanced Mail,打开看文本格式,以”—–BEGIN…”开头, “—–END…”结尾,内容是BASE64编码.
查看PEM格式证书的信息:openssl x509 -in certificate.pem -text -noout
Apache和*NIX服务器偏向于使用这种编码格式.
DER - Distinguished Encoding Rules,打开看是二进制格式,不可读.
查看DER格式证书的信息:openssl x509 -in certificate.der -inform der -text -noout
Java和Windows服务器偏向于使用这种编码格式.
相关的文件扩展名
这是比较误导人的地方,虽然我们已经知道有PEM和DER这两种编码格式,但文件扩展名并不一定就叫”PEM”或者”DER”,常见的扩展名除了PEM和DER还有以下这些,它们除了编码格式可能不同之外,内容也有差别,但大多数都能相互转换编码格式.
CRT - CRT应该是certificate的三个字母,其实还是证书的意思,常见于*NIX系统,有可能是PEM编码,也有可能是DER编码,大多数应该是PEM编码,相信你已经知道怎么辨别.
CER - 还是certificate,还是证书,常见于Windows系统,同样的,可能是PEM编码,也可能是DER编码,大多数应该是DER编码.
KEY - 通常用来存放一个公钥或者私钥,并非X.509证书,编码同样的,可能是PEM,也可能是DER.
查看KEY的办法:openssl rsa -in mykey.key -text -noout
如果是DER格式的话,同理应该这样了:openssl rsa -in mykey.key -text -noout -inform der
CSR - Certificate Signing Request,即证书签名请求,这个并不是证书,而是向权威证书颁发机构获得签名证书的申请,其核心内容是一个公钥(当然还附带了一些别的信息),在生成这个申请的时候,同时也会生成一个私钥,私钥要自己保管好.做过iOS APP的朋友都应该知道是怎么向苹果申请开发者证书的吧.
查看的办法:openssl req -noout -text -in my.csr (如果是DER格式的话照旧加上-inform der,这里不写了)
PFX/P12 - predecessor of PKCS#12,对*nix服务器来说,一般CRT和KEY是分开存放在不同文件中的,但Windows的IIS则将它们存在一个PFX文件中,(因此这个文件包含了证书及私钥)这样会不会不安全？应该不会,PFX通常会有一个”提取密码”,你想把里面的东西读取出来的话,它就要求你提供提取密码,PFX使用的时DER编码,如何把PFX转换为PEM编码？
openssl pkcs12 -in for-iis.pfx -out for-iis.pem -nodes
这个时候会提示你输入提取代码. for-iis.pem就是可读的文本.
生成pfx的命令类似这样:openssl pkcs12 -export -in certificate.crt -inkey privateKey.key -out certificate.pfx -certfile CACert.crt
其中CACert.crt是CA(权威证书颁发机构)的根证书,有的话也通过-certfile参数一起带进去.这么看来,PFX其实是个证书密钥库.
JKS - 即Java Key Storage,这是Java的专利,跟OpenSSL关系不大,利用Java的一个叫”keytool”的工具,可以将PFX转为JKS,当然了,keytool也能直接生成JKS,不过在此就不多表了.
证书编码的转换
PEM转为DER openssl x509 -in cert.crt -outform der -out cert.der
DER转为PEM openssl x509 -in cert.crt -inform der -outform pem -out cert.pem
(提示:要转换KEY文件也类似,只不过把x509换成rsa,要转CSR的话,把x509换成req…)
获得证书
向权威证书颁发机构申请证书
用这命令生成一个csr: openssl req -newkey rsa:2048 -new -nodes -keyout my.key -out my.csr
把csr交给权威证书颁发机构,权威证书颁发机构对此进行签名,完成.保留好csr,当权威证书颁发机构颁发的证书过期的时候,你还可以用同样的csr来申请新的证书,key保持不变.
或者生成自签名的证书
openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
在生成证书的过程中会要你填一堆的东西,其实真正要填的只有Common Name,通常填写你服务器的域名,如”yourcompany.com”,或者你服务器的IP地址,其它都可以留空的.
生产环境中还是不要使用自签的证书,否则浏览器会不认,或者如果你是企业应用的话能够强制让用户的浏览器接受你的自签证书也行.向权威机构要证书通常是要钱的,但现在也有免费的,仅仅需要一个简单的域名验证即可.有兴趣的话查查”沃通数字证书”.