Posts

访问控制（AC）的发展历程 访问控制（Access Control, AC）是保护系统资源的重要机制，决定“谁”可以访问“哪些”资源，并能执行“哪些操作”。它的核心目标是防止越权访问和恶意操作，从而保障系统安全和数据机密性。访问控制技术的历史可以追溯到 20 世纪 60-70 年代，几乎与计算机的诞生同步。经过数十年的发展，访问控制模型从MAC（强制访问控制）演进到 ABAC（基于属性的访问控制），不同阶段的技术各有特点，适用于不同的场景。 AC 的演进阶段 访问控制技术的发展经历了以下关键阶段： MAC（强制访问控制，Mandatory Access Control） 特点：最早出现的访问控制模型，由系统统一管理权限，用户无法修改自己的权限。 优点：安全性高，适用于军事、政府等高安全要求的环境。 缺点：灵活性低，难以适应企业或商业应用。 DAC（自主访问控制，Discretionary Access Control） 特点：资源的所有者可以自行分配权限，比如文件的拥有者可以决定谁能读取或修改它。 优点：灵活性高，易于实现，适用于个人电脑、文件系统等应用场景。 缺点：权限管理分散、缺乏统一性，可能导致安全漏洞。 RBAC（基于角色的访问控制，Role-Based Access Control） 特点：用户被分配角色，权限与角色绑定，用户继承角色的权限，而不是直接分配权限。 优点：简化权限管理，特别适用于企业和组织化管理，可以减少手动管理的复杂度。 缺点： 细粒度控制能力有限，难以满足复杂权限需求。 “角色爆炸” 问题：当组织规模扩大时，角色数量可能大幅增加，导致管理复杂化。 ABAC（基于属性的访问控制，Attribute-Based Access Control） 特点：通过用户、资源和环境的属性动态计算访问权限，而不是固定的角色分配。 优点： 更灵活，可以支持复杂的权限需求，适用于云计算、大型企业、跨组织合作等场景。 动态调整权限，可以基于实时环境（如访问时间、地点、设备）调整权限。 缺点：管理复杂度较高，需要更强的策略管理能力和计算资源。 AC 的发展趋势 总体来看，访问控制技术正在从静态、粗粒度控制向动态、细粒度管理演进，以适应日益复杂的 IT 环境和安全需求。 早期的 MAC 强调安全性和统一管理，但缺乏灵活性。 DAC 和 RBAC 提高了灵活性和可管理性，尤其是 RBAC 适用于企业组织管理，至今仍是许多企业的主要访问控制模式。 ABAC 将灵活性提升到新高度，通过属性组合实现更细粒度的权限管理，适用于云计算和复杂安全需求的企业。 尽管 RBAC 目前仍然是企业访问控制的主流，但 ABAC 由于其强大的灵活性，正在越来越多地被采用，尤其在需要动态权限调整和细粒度控制的场景下。 未来，RBAC 和 ABAC 的混合模式（RBAC-ABAC）可能成为新的趋势，即RBAC 用于管理基础权限，ABAC 用于细粒度控制，这样既能保证管理的简便性，又能提升系统的安全性和灵活性。 ABAC 的概述说明 ABAC（Attribute-Based Access Control，基于属性的访问控制） 是一种动态、细粒度的访问控制方式，与传统的 RBAC（基于角色的访问控制） 和 ACL（访问控制列表） 不同，ABAC 不依赖预定义的角色或权限，而是根据用户、资源和环境等属性实时计算访问权限。 相比于 RBAC 这样固定的权限模型，ABAC 提供了更强的灵活性，能够基于不同属性动态调整权限。 ...

引言：让 AI 学会"思考"的新突破 在近年来的人工智能浪潮中，大型语言模型（LLM）如 ChatGPT 已经能回答各种问题，但它们在复杂推理方面仍有不足。所谓复杂推理，比如解决奥数难题、编写复杂代码或进行多步逻辑推导，这些都相当于让 AI “动脑筋"思考多步。以前的 AI 往往容易在这些任务中出错。DeepSeek-R1 的出现标志着一个重要突破：研究者找到了一种新方法，让 AI 通过强化学习反复试错，逐渐学会像人一样多步推理问题更棒的是，DeepSeek-R1 是完全开源的，这意味着任何人都可以使用它，不用依赖收费的商用 AI 服务。下面我们将用通俗的语言介绍 DeepSeek-R1 的核心理念、它是如何训练的，以及它能带来什么应用价值。 核心理念：用强化学习培养 AI 的"逻辑思维” DeepSeek-R1 的核心思想是模拟人类解题的过程来训练 AI。想象我们教一个学生解数学题：一开始学生并不知道怎么下手，但通过不断尝试、犯错、再纠正，他的解题思路会越来越清晰。DeepSeek-R1 的训练就类似这样，只不过这里学生是 AI，老师不是人，而是奖励和惩罚机制。研究者让模型尝试回答各种复杂问题，然后用程序自动检查答案对不对，对正确的过程给予奖励，错误的则不给奖励。在成千上万次这样的训练循环后，模型会倾向于采用能得高分的推理策略，慢慢地就学会了复杂问题的解法。这种训练方法被称为强化学习（Reinforcement Learning），因为模型通过"强化"成功的尝试来学习。DeepSeek-R1 特别之处在于：它在训练初期没有人工示范，完全靠自己摸索。研究者先让一个基础模型（DeepSeek-V3-Base）直接进入强化学习，就像让 AI 小孩自己玩谜题，结果这个模型（称为 DeepSeek-R1-Zero）居然自己悟出了很多强大的解题技巧！比如，它学会了反思自己的答案、尝试不同思路等，这些都是人类优秀解题时会用的策略。可以说，经过强化学习，“小孩"已经变成了有创造力的"数学家”，只是有时候表达还不太通顺。 但是，仅靠自我摸索的 R1-Zero 也有明显的问题：它给出的答案有时很难读懂，甚至会中英混杂，或者回答偏离人们习惯的表达方式。这就好比一个钻研技术的极客，思路很厉害但是说话让人抓不住重点。为了解决这个问题，研究者对模型进行了两次额外的指导调整：第一次是喂给它一些**“冷启动"例子**，相当于给模型打好基础，让它知道回答时基本的礼仪和清晰度。第二次是在强化学习之后，研究者收集了模型在训练中表现优秀的解题示例，再混合一些人工整理的题目，重新训练模型一次。这一步就像老师看到学生自己总结了一些很好的解题方法，帮他整理成笔记巩固学习。经过这两轮调整，模型的表达流畅了，知识面也更广了。这时再让模型进行最后一轮强化学习，让它面对各种类型的问题训练，相当于毕业前的全面模拟考试。最终诞生的 DeepSeek-R1 模型，既有缜密的推理能力，又能用清晰自然的语言给出答案。 总结起来，DeepSeek-R1的训练流程可以用以下步骤概括： 预热训练：先用一些人工整理的问答对，教模型基本的回答规范（确保它回答不牛头不对马嘴）。 自我尝试：不给示范，直接让模型挑战各种推理难题，通过试错积累经验（强化学习阶段）。 优例精炼：收集模型在尝试中表现好的范例答案，再训练模型一次，让它学会用更好的表述和思路回答。 综合考核：最后，再让模型在混合了所有类型问题的环境下强化学习一次，确保它在各方面表现均衡、稳健。 通过这样的流程，DeepSeek-R1就像一个经历了自学、纠错、再学习、再实战的学生，最终成长为解题高手。 能力与表现：媲美顶尖 AI 的开源模型 DeepSeek-R1 经过上述训练，达到了令人惊艳的水平：在许多困难测试上，它的表现几乎追上了目前最强的闭源 AI 模型 OpenAI-o1。例如： 在数学考试中，DeepSeek-R1 的得分与 OpenAI 的顶级模型几乎持平。针对美国高中数学竞赛（AIME）的测试，R1 答对了 79.8% 的问题，而 OpenAI-o1 答对了 79.2%—两者几乎一样好。这说明 R1 已经能够解决非常复杂的数学题，而这往往被视为 AI 难以企及的挑战。更夸张的是，在一份包含 500 道高难度数学题的测验中，R1 的准确率高达 97.3%，和 OpenAI-o1 的 96.4% 相当。可以想象，这样的成绩甚至超过了很多人类参赛者。 在编程方面，DeepSeek-R1 表现出接近资深程序员的水准。研究者让它参加编程竞赛平台 Codeforces 的挑战，结果 R1 的积分相当于超过 96% 的人类选手！OpenAI-o1 也很强，但 R1 略胜一筹。这意味着 R1 不仅会写简单代码，还能解决竞赛级别的算法难题，能够当作编程助手来使用。 在常识问答和知识测验上，DeepSeek-R1 同样表现亮眼。在一个涵盖历史、文学、科学等各种领域知识的 MMLU 考试中，R1 的得分接近 91%，几乎和 OpenAI-o1 不相上下。要知道，这种考试涉及广博的知识和理解能力，R1 展现出接近人类专家的水平。此外，OpenAI 发布的一项新测验 SimpleQA（考查模型回答简单常识问题的准确性），R1 也击败了它的前辈模型 DeepSeek-V3，证明它不仅会推理，连知识问答也更胜一筹。 简单来说，DeepSeek-R1 已经在数学、逻辑和代码这"三座大山"上站到了开源模型的顶峰，甚至与目前最先进的闭源模型平起平坐。这对于开源社区和普通用户意义重大：以前这些顶尖能力只存在于少数公司的保密模型中，而现在一个免费开放的模型就能实现。 ...

概述 现代密码学对信息的处理主要离不开以下的三种形式： 摘要：主要用于数据校验，例如存储密码等，摘要是对信息进行单向的哈希，改变信息的原有形态，因为哈希函数的特点是易变性（即使微小的变化也会产生完全不同的哈希值），而且无法被反向推导出来，例如上文提到常见的哈希加密方式有：MD2/4/5/6、SHA0/1/256/512 算法等方式。 加密：主要用于保证信息的安全传输，确保真实的信息只能被授权的人访问（拥有密钥），通常使用密钥对信息进行加密，和摘要不同的是，加密是可以解密为明文信息的。密钥的类型又分为：对称型密钥，非对称型密钥（公钥、私钥）等，常见的有 DES、AES、RC4、IDEA 等方式。 签名：主要是用来保证明文信息的完整性、真实性和检查是否被篡改的一种方式（使用哈希函数），例如 jwt 令牌 中就是有一段签名，用于保证负载信息的真实性，签名并不保证信息的私密性。 总体来说，它们的分工是： 摘要：用于确保数据的完整性和快速比较，无法被解密。 加密：用于保护数据的机密性，它和摘要的区别是加密可以逆向破解，也就是解密。 签名：则提供了一种验证消息来源和完整性的方法。但信息是公开的。 这三者共同构成了现代密码学的基石，广泛应用于数据保护、身份验证和网络安全等领域。 密钥 对称型密钥 对称型密钥加密的基本原理是将明文数据通过一个加密算法和一个密钥转换成密文，然后接收方使用相同的密钥和解密算法将密文还原成原始的明文。由于加密和解密都使用同一个密钥，因此被称为对称加密。对称型密钥加密算法的特点是算法简单、速度快，适合于大量数据的加密。常见的对称型密钥加密算法包括：AES (Advanced Encryption Standard)、DES (Data Encryption Standard)、3DES (Triple DES)。 对称型密钥在密钥的保管和分发上面存在困难，因为密钥必须安全地分发给所有需要它的用户，并且每次通信都需要一个新的密钥，这在大规模通信中可能会变得复杂。关于对称型密钥总结如下： 优点：加解密速度快，适合大量数据、算法简单，资源消耗低，适合大量数据的加解密的场景。 缺点：密钥的保存和分发困难：无法在不可信的网络上进行分发，存在 “先有鸡，还是先有蛋” 的问题。 非对称型密钥 非对称型密钥加密，也称为公钥加密或双密钥加密，是一种使用两个不同密钥的加密方法：一个用于加密（称为公钥），另一个用于解密（称为私钥）。公钥可以公开分享，而私钥则必须保密。 非对称加密的基本原理是： 密钥生成：首先生成一对密钥，包括一个公钥和一个私钥。这两个密钥是数学上相关的，但即使知道了公钥，也无法轻易推导出私钥。 加密：当 A 想要向 B 发送加密信息时，A 会使用 B 的公钥来加密信息。这样，只有拥有相应私钥的 B 才能解密这条信息。 解密：B 收到加密信息后，使用自己的私钥来解密，恢复原始信息。 非对称加密的关键特性是公钥可以公开，而私钥必须保密。这使得非对称加密在某些应用场景中非常有用，但非对称加密的主要缺点是计算复杂，消耗资源，速度慢等，因此它通常与对称加密结合使用：非对称加密用于安全地交换对称密钥，然后使用对称密钥进行实际的数据加密，以提高效率。使用非对称型密钥主要解决两个不信任个体在不安全通信环境下的信息传输问题，解决信息在公开网络中传输的问题，既然被截获也不会受到影响。关于非对称型密钥总结如下： 优点：使用密钥对解决密钥分发的问题，可以在公开网络中安全传输信息 缺点：速度慢，不适合对大量数据进行加密，计算资源消耗高，拥有长度的限制多长的密钥只能加密多长的明文。 因此，对称密钥和非对称密钥的区分是为了满足不同的安全需求、提高效率、简化密钥管理，并适应不同的通信场景。单独依靠某一种算法（对称加密、非对称加密）既做不了加密，也做不了签名。在实际应用中，对称加密和非对称加密往往是结合使用的。已混合加密方式来保护信道安全。 具体做法： 使用非对称加密方式，协商一个密钥（少量信息）给通信的另一方 双方基于共同的密钥进行对称加密传输大量的信息 混合使用对称和非对称加密方法来传输信息，这样可以同时利用两种加密方式的优势，也称为现代密码学套件。信息传输的终极解决方案 HTTPS 就是基于该方式实现的。 证书 在现实生活中，我们要和一个未曾谋面的人建立信任，通常有两种方式： 基于共同的私密信息：对方打电话来说是我的小学同学，他能说出我们小学还有同学的名字，做过的一些糗事，那么我就会信任他 基于权限的公证人：对方说他是警察，需要我配合办案，如果他能提供证件和警员编号，那么我们也会信任他，并且进行配合 在网络世界里面，我们不能认为两台计算机是相互认识并且存在共同的私密信息的，所以解决信任问题只有基于第二种 基于权限的公证人 的方式。 CA 认证中心 CA 认证中心是负责给计算机的服务端颁发数字证书（Certificate）的机构，类似于上面例子中给警察颁发证件的权威机构类似。当客户端访问服务端时，会检查服务端的证书是有效，确认无误后才会建立安全链接。 ...

概述 在我很喜欢的一部（根据真实事件改编）的电影《模仿游戏》里面：著名的科学家图灵带领他的团队，花费两年的时间，费劲九牛二虎之力，在找到德军的话术口令后才得以破解了德军通讯加密装置 “英格玛”，为第二次世界大战取得胜利打下的坚实的基础。那么德军使用的通讯加密究竟是一种怎样的技术，这是我们今天要探讨的数据加密技术。数据的保密是对数据加密、解密的统称，用学院派的说法就是，**使用某种算法改变了信息原本的形态，使攻击者即使窃取了信息也因为没有对应的解密的方法也无法获取当信息的真实内容。**这就是信息保密的目的，对于信息的保密，可以在三个环节进行，分别是： 在客户端进行保密 在传输时进行保密（最复杂，也最有效） 在服务端进行保密 加密的强度 在安全领域大家都知道安全是区分等级的，不同应用的敏感信息重要性不同，所以需要的安全等级也不同，这个世界上没有绝对的安全，安全等级不可能无止境的拉满，任何安全手段都可以破解（只要花费足够的成本），想要更高级别的安全等级，就要付出更高的成本（工作量，算力）等。例如常见的加密技术可以说明这一点。加密的强度从低到高，分别有： 一：哈希算法：最常见的加密手段，对明文密码使用 MD5 等哈希摘要算法进行不可逆的哈希计算进行加密，示例： import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; public class MD5Hash { public static void main(String[] args) { String text = "yourPassword"; try { MessageDigest md = MessageDigest.getInstance("MD5"); byte[] hashBytes = md.digest(text.getBytes()); StringBuilder hexString = new StringBuilder(); for (byte b : hashBytes) { hexString.append(String.format("%02x", b)); } System.out.println("MD5 Digest: " + hexString.toString()); } catch (NoSuchAlgorithmException e) { e.printStackTrace(); } } } 输出结果： MD5 Digest: 65a8e27d8879283831b664bd8b7f0ad4 这种方式，安全等级低，弱密码容易被彩虹表（预先进行摘要好的哈希表，进行反向破译）破击。 ...

概述 在上一篇文章我们聊完了授权的过程，在服务器对客户端完成授权之后，服务器会给客户端颁发对应的凭证，客户端持有该凭证访问服务端，服务器便能知道你是谁，你有什么权限等信息。这一章我们具体聊聊常见的凭证管理技术有哪些。 在软件架构中，关于凭证如何存储和传递，一直有两种不同的解决思路，两种不同的解决方式，实际上反映了两种不同的架构思路： 一种是把所有状态信息都放在服务器端 （Cookie-Session 方案） 一种是把所有状态将信息存储在客户端（JWT 方案） 在互联网早期，这个问题早就有了明确的答案。大多数应用都采用了 “Cookie-Session” 的方法，这种方法通过在服务器上存储用户状态，来实现用户身份的识别和信息的传递。这种方法在很长一段时间里都是主流。 然而，随着微服务和分布式系统的兴起，我们发现由于 CAP 的限制，服务器端存储状态信息的方式开始面临很多问题（微服务要求服务端本身是无状态，才能实现动态扩缩容）。这就迫使我们重新考虑被放弃的客户端状态存储方法。在这个背景下，JWT（JSON Web Token）的令牌的方案开始受到关注。JWT 是一种在客户端存储用户状态信息的方式，它允许用户在不同的服务器之间自由切换，而不需要重新登录。这种特性在分布式系统中非常有用。但是要明白，JWT 和 Cookie-Session 只是对授权信息存储的主体（客户端，服务端）不同，各有优势，合适场景不同，不存在谁比谁要先进的问题。在本节中，我们将探讨 Cookie-Session 和 JWT 两种方案的相同点和不同点，帮你更好地理解这两种方案的优缺点，以及它们在不同场景下的应用。 cookie-session 总所周知，因为 HTTP 是无状态协议，所以 Cookie-Session 的原理其实很简单，就是解决 HTTP 协议无状态的问题，在 RFC 6265 中定义了 HTTP 的状态管理机制，增加 Set-Cookie 指令，服务端向客户端发送一组信息（标识）示例： HTTP/1.1 200 OK Content-type: text/html Set-Cookie: session_token=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT; Path=/ 客户端收到指令后在此后一段时间的 HTTP 请求中都发给服务端会话信息（在 Header 中携带 cookie 信息），以便服务器区分不同的客户端： GET /profile HTTP/1.1 Host: www.example.com Cookie: sessionid=xyzasdzxc123789456 客户端的 Cookies 里通常只存储一个无意义，不重复的字符串，通常命名是 sessionid 或 jessionid ，服务端则根据该字符串作为 Key，和用户信息建立关联后存储在服务端的内存或者缓存中。再辅以一些超时自动清理的措施来管理会话。 ...

概述 在安全管理系统里面，授权（Authorization）的概念常常是和认证（Authentication）、账号（Account）和审计（Audit）一起出现的，并称之为 4A。就像上一文章提到的，对于安全模块的实现，最好都遵循行业标准和最佳实践，授权也不例外。 作为安全系统的一部分，授权的职责如下： 确保授权过程的可控：常见的参考标准有 OAuth2、SAML2、CAS 等协议 确保授权结果的可控：常见的参考标准有 RBAC、ABAC 等授权模型 对于大多数应用来说，主流的做法是基于 OAuth2 + RBAC 的组合搭配实现授权。下面就从这两个方向展开聊聊。 RBAC RBAC（角色基础访问控制）是一种常见的权限管理方式。在这种模型中，系统根据用户的角色来分配权限，而不是直接分配给单个用户。这样可以简化权限管理和配置的复杂性。避免频繁的对用户进行权限操作。如下： 如果还有更复杂的访问控制需求，则可以在 RBAC0 的基础上可以扩展 RBAC1 （层次化 RBAC，角色之间有继承关系）和 RBAC2（受约束的 RBAC，角色之间有互斥关系）来提高系统的安全性和管理的便利性。还有 RBAC 3 等等。 对于大多数应用来说，通常都无需自己去实现这些理论的模型，应用遇到的安全问题大多都是相同的，具有普遍性，所以可以抽象到框架层面来解决，例如著名的 Spring Security 框架就提供 RBAC 模型的授权实现。 不过，需要特别说明的是，与具备通用性的访问控制权限相比，对于数据权限的控制则显的困难的多，用户能访问的数据权限通常与业务高度关联，具体到不同部门，不同角色，甚至指定人员可以访问的数据权限都不尽相同。完全不具备通用性，所以无法通过框架层面解决，就连 Spring Security 框架也未能提供数据权限的相关控制。只能有业务系统结合实际情况各自在业务层实现，这也是目前无法解决的问题。 OAuth 2 OAuth2 是一种业界标准的授权协议，允许用户授权第三方应用程序访问他们在其他服务提供者上的资源，而无需分享用户名和密码，它定义了四种授权交互模式，适用于各种应用场景： 授权码模式 隐式授权 用户模式 应用模式 OAuth2 通过发放访问令牌（Access Token）和刷新令牌来实现对受保护资源的访问控制。通过创新的使用访问令牌 Token 替代了用户密码，避免用户凭证的泄露。 授权码 授权码模式可以说是最安全的授权模式，综合考虑了各种风险和防范措置，但相对也是最复杂的授权协议，适合有服务端可以存储密钥（ClientSecret）的场景，授权流程如下： 看完授权码的过程，你可能会觉得好奇：为什么授权服务器要返回授权码，而不直接返回令牌呢 ？ 返回授权码而不是直接返回令牌的设计主要是为了提高安全性，原因如下： 即使授权码被截获，攻击者因为没有客户端密钥无法获取访问令牌，客户端密钥只在服务器端保存，不会通过前端暴露。 在重定向回客户端应用的过程中，授权码会通过浏览器传输。如果直接传输访问令牌，一旦泄露，就会带来更高的安全风险。授权码则可以进行严格的限制（如一次性使用，很短的有效期），所以即使泄露也难以被利用。 在客户端使用授权码请求访问令牌时，授权服务器可以验证请求中包含的客户端密钥和重定向 URI 等信息，确保令牌的请求合法 另外令牌颁发的策略上，授权码模式下也使用长刷新令牌 + 短访问令牌的双令牌策略，来最大化减少 JWT 令牌无状态难回收的问题。因此，在服务端可以存储令牌的前提下，授权码模式可以说是大多数场景下的首选。 隐式授权 隐式授权模式对于实在没有服务端存储 ClientSecret 的纯前端应用提供接入支持。接入流程也比较简单，如下： ...

概述 几乎所有的系统都会面临安全认证相关的问题，但是安全相关的问题是一个很麻烦的事情。因为它不产生直接的业务价值，而且处理起来复杂繁琐，所以很多时都容易被忽视。很多后期造成重大的安全隐患，往往都是前期的不重视造成的。但庆幸的是安全问题是普遍存在的，而且大家面临的问题几乎相同，所以可以制定行业标准来规范处理，甚至是可以抽出专门的基础设施（例如：AD、LDAP 等）来专门解决这类共性的问题。总之，关于安全问题非常复杂而且麻烦，对于大多数 99% 的系统来说，不要想着在安全问题领域上搞发明和创新，容易踩坑。而且行业的标准解决方案已经非常成熟了。经过长时间的检验。所以在安全领域，踏踏实实的遵循规范和标准就是最好的安全设计。 HTTP 认证 HTTP 认证协议的最初是在 HTTP/1.1标准中定义的，后续由 IETF 在 RFC 7235 中进行完善。HTTP 协议的主要涉及两种的认证机制。 基本认证 常见的叫法是 HTTP Basic，是一种对于安全性不高，以演示为目的的简单的认证机制（例如你家路由器的登录界面），客户端用户名和密码进行 Base64 编码（注意是编码，不是加密）后，放入 HTTP 请求的头中。服务器在接收到请求后，解码这个字段来验证用户的身份。示例： GET /some-protected-resource HTTP/1.1 Host: example.com Authorization: Basic dXNlcjpwYXNzd29yZA== 虽然这种方式简单，但并不安全，因为 base64 编码很容易被解码。建议仅在 HTTPS 协议下使用，以确保安全性。 摘要认证 主要是为了解决 HTTP Basic 的安全问题，但是相对也更复杂一些，摘要认证使用 MD5 哈希函数对用户的密码进行加密，并结合一些盐值（可选）生成一个摘要值，然后将这个值放入请求头中。即使在传输过程中被截获，攻击者也无法直接从摘要中还原出用户的密码。示例： GET /dir/index.html HTTP/1.1 Host: example.com Authorization: Digest username="user", realm="example.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" **补充：**另在 RFC 7235 规范中还定义当用户没有认证访问服务资源时应返回 401 Unauthorized 状态码，示例： HTTP/1.1 401 Unauthorized WWW-Authenticate: Basic realm="Restricted Area" 这一规范目前应用在所有的身份认证流程中，并且沿用至今。 Web 认证 表单认证 虽然 HTTP 有标准的认证协议，但目前实际场景中大多应用都还是基于表单认证实现，具体步骤是： ...

Controller Manager Controller Manager 是控制平面的一个重要组件，负责维护 Kubernetes 集群的整体状态。 流程： 在集群中 Controller Manager 主要做以下几件事情： 监听： Controller Manager 通过 API Server 监听集群中的资源状态变化。当资源状态发生变化时，Controller Manager 会收到通知。 决策： Controller Manager 会根据资源的定义和状态做出决策。如果一个 Deployment 的 Pod 数量低于预期，Controller Manager 会创建新的 Pod。 执行： Controller Manager 会根据决策，执行相应的操作。例如，如果要创建新的 Pod，Controller Manager 会调用 API Server 来创建 Pod。 常见的 Controller Kubernetes 中内置了许多 Controller，当资源状态发生变化时，Controller Manager 会通知这些 Controller 做出决策和执行操作。 Deployment Controller：负责部署和管理 Pod 副本。 ReplicaSet Controller：负责管理 Pod 副本的数量。 DaemonSet Controller：确保每个节点都运行指定的 Pod。 Job Controller：负责执行一次性任务。 CronJob Controller：负责按照指定的频率执行任务。 StatefulSet Controller：确保 Pod 的顺序性和持久性。 Cloud Controller Manager ...

概述 kube-scheduler 是 Kubernetes 集群的核心组件之一，它负责为新创建的 Pods 分配节点。它根据多种因素进行决策，包括： 资源需求和限制：考虑每个 Pod 请求的资源量（如 CPU 和内存）以及节点上可用的资源。 亲和性和反亲和性规则：根据 Pod 的亲和性设置选择最适合的节点。 健康检查：确保选择的节点健康且能够运行 Pod。 负载均衡：尽量平衡集群中各个节点的负载。 使用 limits 和 reuqests 在部署对象中的 spec 中常常会见到关于 limits 和 requests 的声明 ，例如： apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 1 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx resources: limits: memory: 1Gi cpu: 1 requests: memory: 256Mi cpu: 100m 这里的 limits 和 requests 是与 Pod 容器资源管理相关的两个关键概念： Limits：指定容器运行时能够使用的最大资源量 Requests：指定容器启动时最低需要的资源量 limits 和 requests 跟 scheduler 有什么关系 ？ ...

概述 etcd 是一个基于 Raft 协议实现。开源的、分布式的键值存储系统。主要用于在分布式系统中提供强一致性和高可用性的数据存储。etcd 在 Kubernetes 中的作用如下： 集群状态数据存储：集群配置，集群状态信息等 保证集群一致性和高可用：多实例的数据同步 服务发现和配置共享 集群数据备份和恢复 作为 Kubernetes 的核心组件，etcd 为集群的稳定性、可靠性和一致性提供了支撑。 安装 命令行启动 安装参考官方文档 etcd install 指引即可，安装后验证： $ etcd --version 输出： etcd Version: 3.5.10 Git SHA: 0223ca52b Go Version: go1.21.3 Go OS/Arch: darwin/arm64 phoenix@xiaobindeMacBook-Pro ~ % etcd 在终端启动 etcd： $ etcd 输出： {"level":"warn","ts":"2023-11-23T06:59:49.265098+0800","caller":"embed/config.go:676","msg":"Running http and grpc server on single port. This is not recommended for production."} {"level":"info","ts":"2023-11-23T06:59:49.265318+0800","caller":"etcdmain/etcd.go:73","msg":"Running: ","args":["etcd"]} {"level":"info","ts":"2023-11-23T06:59:49.265352+0800","caller":"etcdmain/etcd.go:100","msg":"failed to detect default host","error":"default host not supported on darwin_arm64"} {"level":"warn","ts":"2023-11-23T06:59:49.265361+0800","caller":"etcdmain/etcd.go:105","msg":"'data-dir' was empty; using default","data-dir":"default.etcd"} #..... 容器启动 在容器中启动 etcd 实例： ...