pki

1. 数据传输分类 在互联网上数据传输有两种：明文传输和加密传输。明文传输的协议有：ftp、http、smtp、telnet。但是为了数据的完整性和安全性，所以后来引用了加密等相关手段来保证数据的安全和完整性。 2. 案例引入 我在外地出差，因工作需要，公司主管要发给我一份重要资料给我，怎么才能让这个资料顺利的传到我的手上，而且我怀疑有人会窃取这个重要资料，若是被谁窃取到那公司损失就大了！ 3. 安全的特点 我能确定这个资料来来自公司 --- 数据来源认证 我能确保在通过因特网传输时没有被修改过 --- 数据的完整性保护（传输的过程中是否被修改） 确宝没有别人能够看到这份资料 --- 数据私密性 （不能被别看到） 主管不能事后否认他曾经发送过那份资料本给我 ---（不可否认性） 4. 角色说明 互联网 黑客 数据 加密 数据 5. 算法 (1). 密码学算法主要分为两个大类，对称加密算法和非对称加密算法，对称加密算法技术已经存在了很长的时间。最早在埃及使用！ (2). 我们很快就能看到，对称加密算法和非对称加密算法各有所长和弱点，所以现代密码系统都在努力做到适当地使用这两类算法以利用它们的长处，同时又避开它们各自的缺点。 6. 对称加密算法的加密和解密原理 对称加密算法概念： 使用相同密钥与算法进行加解密运算的算法就叫做对称加密算法 具体加密过程如下图： 7.

傻傻分不清楚的kubernetes证书 kubeadm 生成的一坨证书是不是让人很蒙逼，这些东西没那么神奇，来深入扒扒其内裤。 root@k8s-master:/etc/kubernetes/pki# tree . |-- apiserver.crt |-- apiserver-etcd-client.crt |-- apiserver-etcd-client.key |-- apiserver.key |-- apiserver-kubelet-client.crt |-- apiserver-kubelet-client.key |-- ca.crt |-- ca.key |-- etcd | |-- ca.crt | |-- ca.key | |-- healthcheck-client.crt | |-- healthcheck-client.key | |-- peer.crt | |-- peer.key | |-- server.crt | `-- server.key |-- front-proxy-ca.crt |-- front-proxy-ca.key |-- front-proxy-client.crt |-- front-proxy-client.key |-- sa.key `-- sa.pub 1 directory, 22 files 从RSA说起

添加EPEL源 yum install epel-release -y 替换阿里的源 sed -e 's,^#baseurl,baseurl,g' \ -e 's,^metalink,#metalink,g' \ -e 's,^mirrorlist=,#mirrorlist=,g' \ -e 's,http://download.fedoraproject.org/pub,https://mirrors.aliyun.com,g' \ -i /etc/yum.repos.d/epel.repo 更新软件 yum makecache yum update -y 修改sysctl参数 cat > /etc/sysctl.d/99-net.conf <<EOF # 二层的网桥在转发包时也会被iptables的FORWARD规则所过滤 net.bridge.bridge-nf-call-arptables=1 net.bridge.bridge-nf-call-iptables=1 net.bridge.bridge-nf-call-ip6tables=1 # 关闭严格校验数据包的反向路径，默认值1 net.ipv4.conf.default.rp_filter=0 net.ipv4.conf.all.rp_filter=0 # 设置 conntrack 的上限 net.netfilter

某厂面试归来，发现自己落伍了！>>> 之前的方式只是实现1:1的模式，昨天同事继续实现了n:1的模式，这里我再整理记录下。 由于nginx的ssl_client_certificate参数只能指定一个客户端公钥，如果增加一个客户端进行通信就要重新配一个server。 n:1的模式是通过CA的级联证书模式实现的，首先 自己 生成一套CA根级证书，再借助其生成二级证书作为client证书。 此时client私钥签名不仅可以通过对应的client公钥验证，还可通过根证书的公钥进行验证。 看到这里应该豁然开朗了吧，下面简单介绍下具体怎么操作： 1 准备工作 1.1 openssl目录准备 一般情况下openssl的配置文件都在这个目录 /etc/pki/tls ，so： mkdir /etc/pki/ca_linvo cd /etc/pki/ca_linvo mkdir root server client newcerts echo 01 > serial echo 01 > crlnumber touch index.txt 1.2 openssl配置准备 修改openssl配置 vi /etc/pki/tls/openssl.cnf 找到这句注释掉，替换为下面那句 #default_ca = CA_default default_ca = CA_linvo 把 [ CA

准备 在开始部署 k8s 高可用集群时，请先参考 k8s高可用环境部署系统准备 操作系统兼容性 环境说明 集群部署前系统环境装备，请参考 k8s高可用环境部署系统准备.md 本次高可用集群基本参照 官网步骤 进行部署，官网给出了两种 拓扑结构 ：堆叠control plane node和external etcd node，本文基于第一种拓扑结构进行部署，使用 Keepalived + HAProxy 搭建高可用Load balancer，完整的拓扑图如下： 单个mastre节点将部署keepalived、haproxy、etcd、apiserver、controller-manager、schedule六种服务，load balancer集群和etcd集群仅用来为kubernetes集群集群服务，不对外营业。如果必要，可以将load balancer或者etcd单独部署，为kubernetes集群提供服务的同时，也可以为其他有需要的系统提供服务，比如下面这样的拓扑结构： 说明⚠️：这种拓扑结构也对应external etcd node～ 本文仅部署master节点，使用kubeadm部署worker节点非常简单，不在赘述，环境清单： 服务器 主机IP 主机名字 功能 k8s-master01 192.168.246.193 master01 master+etcd

用于签署证书请求、生成吊销列表CRL以及维护已颁发证书列表和这些证书状态的数据库。因为一般人无需管理crl，所以本文只介绍openssl ca关于证书管理方面的功能。 证书请求文件使用CA的私钥签署之后就是证书 ， 签署之后将证书发给申请者就是颁发证书 。 在签署时，为了保证证书的完整性和一致性，还应该对签署的证书生成数字摘要，即使用单向加密算法。 由于 openssl ca命令对配置文件(默认为/etc/pki/tls/openssl.cnf)的依赖性非常强 ，所以建议结合。 在配置文件中指定了签署证书时所需文件的结构，默认openssl.cnf中的结构要求如下： [ CA_default ] dir = /etc/pki/CA # 定义路径变量 certs = $dir/certs # 已颁发证书的保存目录 database = $dir/index.txt # 数据库索引文件 new_certs_dir = $dir/newcerts # 新签署的证书保存目录 certificate = $dir/cacert.pem # CA证书路径名 serial = $dir/serial # 当前证书序列号 private_key = $dir/private/cakey.pem # CA的私钥路径名 其中目录/etc/pki/CA/{certs,newcerts,private