标签 https 下的文章

通过实例理解Web应用的机密管理

本文永久链接 – https://tonybai.com/2023/11/08/understand-go-web-secret-management-by-example

如果你是一个Web应用系统的开发人员,你的日常大概率是“乐此不疲”地做着CRUD的活儿,很少接触到安全方面的内容。如果这时有人和你提到“机密(信息)管理(secret management)”,你大概率会说:那是啥?和我有关系吗?

你只是大多应用系统开发人员中的一个典型代表。现阶段,很多开发人员,尤其是业务应用开发人员在工作中较少甚至没有接触过专门的机密管理系统,在系统设计时也较少考虑到机密管理方面的要求,精力仍主要集中在保证系统功能的正确性、性能等方面。这种对安全的重视程度不够,不了解机密管理的现象较为普遍,下面是一些常见的表现:

  • 明文存储密码、密钥等敏感数据

很多项目依然直接将用户密码、数据库连接密码、第三方服务密钥等信息明文写在代码或配置文件中,存在被攻击者直接获取的风险。

  • 硬编码密钥与密码

重复地在代码中多次硬编码密码、密钥等机密信息,导致不能统一变更及管理。

  • 使用弱密码、未定期更换

使用常见的弱密码,或使用默认或长期不变更的密码,很容易被猜测或破解。

  • 不同环境复用同一密钥

开发、测试、生产环境复用同一密钥,一旦泄露将影响所有环境。

  • 明文传输密码

HTTP传输中明文传递密码,导致可被嗅探截获。

  • 日志中输出明文密码

调试日志中直接输出数据库密码等敏感信息,可能被利用。

  • 缺乏访问控制和审计机制

密钥等资源无访问控制,且操作不被审计,难以追踪。

这些现象的普遍存在表明当前对于机密管理的重要性认知还有待提高,尤其是在当前互联网/移动互联网安全形势日益严峻的情况下,开发人员在系统开发的每个环节都应该意识到机密管理的重要性,并将机密管理纳入开发流程的各个阶段,这可以帮助大家构建出更可靠、安全的系统。

在这篇文章中,我就和大家一起来了解一下什么是机密管理,日常进行Web应用开发过程中该如何集成机密管理来保证机密信息在存储、传输、使用过程中的安全,最后,通过实例的方式来剖析Web应用是如何对一些典型的机密信息进行机密管理的。

1. 认识机密管理

在IT领域,机密管理是一种网络安全最佳实践,用于持续地、自动化地管理和保护数字身份验证凭证(如密码、密钥、API令牌等机密信息),确保这些机密信息只能被经过授权的实体在严格的访问控制下使用。

机密管理拥有一套自己的核心管理措施,包括:

  • 从代码、配置文件和其他未经受保护的区域中删除明文机密信息,将机密信息与代码/配置隔离存储;
  • 执行最小特权(Least Privilege)原则,即设计访问控制时,用户和程序只会被授予执行其任务所需的最小/最低权限;
  • 执行严格的访问控制(尤其是要对所有非人类凭证的访问请求进行验证),并对所有访问进行跟踪和全面审计;
  • 定期对机密信息(secrets)和凭证(credentials)进行轮转(rotate);
  • 自动管理机密信息的全生命周期,例如存储、分发、轮转等,并应用一致的访问策略;
  • … …

机密管理涉及要管理的机密信息的类型包括(但不限于):

  • 用户密码或自动生成的密码
  • API和其他应用程序的密钥(Key)/凭证(包括容器内的密钥/凭证)
  • SSH密钥
  • 数据库和其他system-to-system的密码
  • 用于安全通信、传输和接收数据的私人证书(TLS、SSL 等)
  • RSA和其他一次性密码设备

综合上面信息,我们看到机密管理不仅有一套严格的管理措施,而且要管理的机密信息的类型也是很多,并且随着软件系统复杂性的增加,云原生应用兴起,需要管理的机密类型和数量激增,不仅包括传统的密码和密钥,还有云平台的访问证书、微服务间的通信令牌等;管理难度也会大大提高。远程访问和云部署使得传统的边界安全防护变得困难。机密信息传输和存储的渠道更多,风险也上升。高速迭代的软件交付流程和自动化部署,也要求机密管理能同步地快速响应和自动化,机密管理面临着越来越大的挑战。面对这些挑战,业界迫切需要引入自动化、智能化和专业化的机密管理系统来应对。

2. 机密管理系统

机密管理系统是一套专业的用于集中存储、管理、控制和监控机密信息的安全解决方案。机密管理系统的发展经历了一个从分散到集中、从静态到动态、从本地到云端、从加密到访问控制、从人工操作到DevOps自动集成的发展历程,这个历程大致可分为如下几个阶段:

  • 文件加密阶段

早期开发人员通过对文档和配置文件进行加密来保护机密信息,代表技术是PGP等加密软件。但很显然,这种方式操作不便,不支持访问控制等高级功能。

  • 自建解决方案阶段

企业开始自研一些机密管理解决方案(包括基于一些像KeePass这样的开源项目),但功能有限,更多是局限于满足企业自己的需求,很少支持跨平台和集中管理等功能。

  • 开源机密管理项目

随着云计算时代的到来,开源社区推出了支持云和容器的自动化机密管理项目,例如:VaultKeywhiz等,这些项目的一些公同的功能特性包括:轻量化实现、支持访问控制、提供机密信息版本控制、提供审计功能、提供API便于应用集成、支持与 CI/CD 工具集成、支持Docker、Kubernetes等容器平台等。这一时期的开源机密管理系统大大简化了机密管理流程,为随后的云原生机密管理平台的发展奠定了基础。

注:Keywhiz目前2023年9月宣布不再开发,建议使用Hashicorp Vault。

  • 云原生机密管理平台

在开源机密管理项目的基础之上,这些开源项目背后的开发商以及一些专业的公有云提供商开始面向云原生应用和DevOps,以SaaS形式提供专业的机密管理服务和全面的机密管理解决方案,如Azure Key VaultGoogle Secret ManagerAWS Secrets Manager、HashiCorp Vault等。

我们看到:专业的机密系统发展到今天的水平,其过程不是一蹴而就的。正是基于历史经验的积累和总结,现代机密管理平台才演化出了面向云原生架构、支持DevOps、细粒度访问控制、机密信息的动态化以及生命周期的自动化管理等先进功能特性。

在上面的优秀的云原生机密管理系统中,HashiCorp Vault是唯一开源且可以私有化部署在企业内部的。HashiCorp公司于2015年发布并开源了Vault,经过多年发展,Vault已经发展成为一款功能强大的企业级机密管理系统,并被广泛视为云原生领域的首选解决方案。

对于普通Web应用开发者而言,既要有机密管理的意识,又要有机密管理的实现手段。HashiCorp Vault的设计目标之一就是将机密管理下沉到平台层面,让应用开发者能够专注于应用程序的开发而无需过多关注机密的管理和保护。

作为Web应用开发者,基于Vault实现Web应用的机密管理是一条非常可行的机密管理方案。通过与Vault的集成,Web应用开发者可以利用Vault提供的丰富功能来处理各种机密管理需求和场景。开发者只需要学习如何使用Vault的API或客户端库与Vault进行交互,就能轻松地访问和管理机密数据,实现机密信息(如数据库凭据、API 密钥等)获取、动态机密信息生成、访问控制、审计和监控等机密管理功能,并且可以减少机密管理的开发和维护的复杂性。

接下来,我就和大家一起简要的了解一下Hashicorp的Vault。

3. 认识Vault

3.1 Vault的架构

如果对Hashicorp这家公司很熟悉,你肯定知道Hashicorp大部分产品(和开源项目)都是由Go开发的,包括consulnomadterraform以及vagrant(vagrant的新版本将切换到go实现)等。

Vault这款优秀的机密管理软件系统继承了Hashicorp的开发基因,也是由Go语言开发的。从2015年至今,Vault已经演化为一个功能强大,但相对也比较复杂的系统,下面是Hashicorp官方架构文档中的一个关于Vault的high level的结构示意图:

从整体架构设计思路来看,vault支持:

  • 高可用性

Vault的架构设计允许部署多个Vault服务器以实现高可用性和容错性,在高可用集群部署模式下,多个vault服务器共享存储后端,并且每个vault服务器可能是两个状态:active和standby。任意时刻集群都只有一个实例处于active状态,所有standby实例都处于热备用状态(hot standby)。只有处于active状态的服务器会处理所有请求;standby服务器会将所有请求重定向到活动Vault服务器,这点与consul的设计是一致的。如果active服务器被sealed、发生故障或失去网络连接,则standby Vault服务器中的一个将成为active实例。

这里有人可能会问:如果只有一个active实例,那么在访问量增大的时候,active实例便会成为热点或性能瓶颈!没错,这是vault开源版本的约束。这个约束在vault的企业付费版中被取消,在付费版中,standby服务器可以接收只读请求,所有只读请求会均衡分担到各个standby实例上,如果standby实例收到写请求,它会将写请求转发给active实例处理。

  • 封存和解封

说高可用性时,我们提到了vault服务器实例的sealed(封存)状态。启动Vault服务器时,它会处于sealed状态。在这种状态下,Vault仅知道访问物理存储的位置和方式,但不知道如何解密存储中数据。在unseal(解封)之前,该vault服务器几乎无法做任何操作。在对处于sealed状态的Vault实例进行任何操作之前,必须对其进行解封(unseal)。

解封操作需要提供解封密钥(unseal keys)。有人注意到了,我用了unseal keys,而不是unseal key,因为解封密钥是由一种名为Shamir’s Secret Sharing的算法分解保存和汇集生成的。Shamir’s Secret Sharing(Shamir的机密分享算法)是一种密码学算法,用于将机密数据(在本文中指的就是“unseal key”)分割成多个部分,称为shares。这些share可以被分发给不同的人,如下图所示:

而只有当足够数量的share被汇集时,才能恢复出原始的机密数据(unseal key),并用恢复出的机密数据进行下一步操作(如下图所示,下图来自Hashicorp官方文档):

在这幅图中,当汇集一定个数的unseal keys’share后,vault就能够重构解封密钥(“unseal key”),然后用它来解密得到根密钥(root key,也称为master key),根密钥再被用来解密得到加密密钥(Encryption key)用于保护所有vault的数据,即这个Encryption key就是后续参与机密数据加解密的密钥。

注:实际生产部署时,究竟要如何对Vault Server进行unseal,HashiCorp提供了一些unseal pattern供大家参考。

  • 加密层

前面架构图中左侧南北横贯多层的部分是Vault的加密层,被称为barrier,负责对Vault数据进行加密和解密,确保数据在存储和传输过程中的机密性和完整性。Vault服务器启动时,会将数据写入存储后端。由于存储后端位于barrier之外,被视为不可信的(与零信任网络理念一致),因此Vault会在将数据发送到存储后端之前对其进行加密。这种机制确保了即便恶意攻击者试获取了对存储后端的访问权限,其拿到的数据仍然保持加密状态。

  • 认证和授权

如下图(来自Hashicorp官方文档),当客户端首次连接到Vault时,需要进行身份验证。Vault提供可配置的认证方法,并在身份验证机制上提供灵活性。操作员可以使用用户名/密码等机制进行身份验证,而应用程序可以使用公钥/私钥或令牌进行身份验证。 Core(核心)负责管理请求的流程,包括流经哪个身份验证方法来确定请求是否有效,并得到关联策略的列表,执行访问控制规则(ACLs),确保审计日志记录,并将请求路由到相应的机密引擎进行处理。

  • 策略管理

策略是一组命名的访问控制规则。Vault内置了一些策略,如”root”策略,允许对所有资源的访问。用户可以创建任意数量的命名策略,并对路径进行细粒度的控制。除非通过策略明确授权,否则不允许进行操作。

  • 机密引擎

Vault使用机密引擎来生成和管理动态机密数据,如临时凭据、API密钥等。机密引擎的类型可以是静态的,如数据库凭据,也可以是动态的,如 AWS IAM凭据。机密引擎根据配置的规则和策略生成和提供机密数据。

  • 审计和日志记录

Vault记录请求和响应的审计日志,并有Audit Broker(审计代理)将其分发到配置的审计设备(audit device)。审计日志用于监控和审计对Vault的访问和操作。

  • Expiration Manager(租期管理)

Vault由Expiration Mgr管理令牌和机密数据的过期,自动回收已过期的客户端令牌和机密数据。

  • Token Store(令牌存储)

Token Store生成和管理客户端令牌,用于进行后续的请求操作。令牌类似于网站登录时发送的 cookie,用于验证客户端的身份和授权。

以上是Vault的主要架构设计思路和各部分的功能范围。Vault的架构保证了安全性、高可用性和可扩展性,使用户能够安全地管理和保护机密信息。

3.2 Vault的安全模型

Vault是做机密信息管理的,其自身安全模型是否完善直接关系到应用系统的安全。Vault官方也十分重视这点,在官方文档中也对其安全模型做了说明,这里梳理一下。

Vault的安全模型旨在提供数据的机密性、完整性、可用性、可追溯性和认证性。以下是Vault安全模型的几个设计要点:

  • 通信安全

Vault要求客户端与服务器之间的通信通过TLS建立安全通道,以确保通信的机密性和完整性。此外,Vault服务器之间的集群通信也使用相互认证的TLS,以保护数据在传输过程中的机密性和完整性。

  • 身份验证和授权

前面说架构时提及过:所有客户端请求必须经过适当的身份验证和授权。当客户端首次进行身份验证时,Vault使用认证方法验证客户端的身份,并返回与其关联的ACL策略列表。每个请求都需要提供有效的客户端令牌,Vault根据令牌验证其有效性,并生成基于关联策略的访问控制列表(ACL)。

  • 数据安全

Vault对于存储在后端的数据,以及在传输过程中的数据,都要求保证安全。Vault使用256位的高级加密标准(AES)密码和96位随机数作为加密密钥,对离开Vault的所有数据进行加密。同时,在解密过程中验证Galios Counter Mode(GCM)的认证标签,以检测任何篡改。

  • 内部威胁保护

Vault关注内部攻击威胁,即已经获得某种程度Vault访问权限的攻击者企图获取未经授权的机密信息。Vault在客户端进行身份验证时,使用事先配置的关联策略列表来生成客户端令牌,并使用严格的默认拒绝策略来进行访问控制。每个策略指定对Vault中路径的访问级别,最终的访问权限由所有关联策略中最高级别的权限决定。

  • 密钥管理

Vault使用Shamir’s Secret Sharing技术来实现密钥的管理和保护unseal key,本质上也是对Root key和Encryption key的保护。只有在提供足够数量的share时,才能恢复unseal密钥,这样可以避免对单个持有者的绝对信任,同时也不需要存储完整的加密密钥。

但需要注意的是,Vault的安全模型并不涵盖所有可能的威胁和攻击,例如对存储后端的完全控制、存储后端中存在的秘密信息的泄露、运行中的Vault实例内存分析等。此外,Vault还依赖于外部系统或服务的安全性,如果这些外部系统存在漏洞或受到攻击,可能会导致Vault中数据的机密性或完整性受到威胁。

说了这么多Vault,Vault究竟长什么样?应该如何用呢?接下来我们简单介绍一下Vault的安装和使用,也是为后续的实例部分做个铺垫。

3.3 Vault的安装

Vault支持多种形式的安装部署,包括基于预编译好的二进制文件(precompiled binary)、基于容器或包管理器等,你甚至可以自己基于源码编译。

我这里使用的是Precompiled binary方式,将Vault直接部署在我的开发环境下,一台MacBook Pro上。

Precompiled binary下载后就是一个可执行文件,把它放到特定路径下,并在PATH环境变量中将这个路径加入进来,环境变量生效后,你就可以在任意路径下使用vault命令了。

下面的命令打印了下载的vault的版本:

$vault -v
Vault v1.15.1 (b94e275f25ccd9011146d14c00ea9e49fd5032dc), built 2023-10-20T19:16:11Z

通过-h命令行参数,可以查看vault的命令帮助信息:

$vault -h
Usage: vault <command> [args]

Common commands:
    read        Read data and retrieves secrets
    write       Write data, configuration, and secrets
    delete      Delete secrets and configuration
    list        List data or secrets
    login       Authenticate locally
    agent       Start a Vault agent
    server      Start a Vault server
    status      Print seal and HA status
    unwrap      Unwrap a wrapped secret

Other commands:
    audit                Interact with audit devices
    auth                 Interact with auth methods
    debug                Runs the debug command
    events
    kv                   Interact with Vault's Key-Value storage
    lease                Interact with leases
    monitor              Stream log messages from a Vault server
    namespace            Interact with namespaces
    operator             Perform operator-specific tasks
    patch                Patch data, configuration, and secrets
    path-help            Retrieve API help for paths
    pki                  Interact with Vault's PKI Secrets Engine
    plugin               Interact with Vault plugins and catalog
    policy               Interact with policies
    print                Prints runtime configurations
    proxy                Start a Vault Proxy
    secrets              Interact with secrets engines
    ssh                  Initiate an SSH session
    token                Interact with tokens
    transform            Interact with Vault's Transform Secrets Engine
    transit              Interact with Vault's Transit Secrets Engine
    version-history      Prints the version history of the target Vault server

注:Vault继承了Hashicorp产品的一贯风格,即将所有功能放到一个程序中,各个功能通过subcommand的形式提供,比如vault server、vault agent、vault proxy等。如果你了解consul,你会发现consul就是这样的。

3.4 Vault的启动(dev模式)

生产环境的Vault部署、配置、启动以及unseal过程还是蛮复杂的,HashiCorp给了一些参考集群架构,这些可以交给运维同学去琢磨。

对于开发人员而言,日常将应用与Vault集成实现机密管理的时候,只需在本机或远程开发机上启动dev模式的Vault实例即可,这里我们也基于dev模式来启动一个单实例的Vault:

$vault server -dev
==> Vault server configuration:

Administrative Namespace:
             Api Address: http://127.0.0.1:8200
                     Cgo: disabled
         Cluster Address: https://127.0.0.1:8201
   Environment Variables: Apple_PubSub_Socket_Render, CLASSPATH, CLISH_PATH, ETCDCTL_API, GITEA_WORK_DIR, GODEBUG, GONOPROXY, GONOSUMDB, GOPATH, GOPRIVATE, GOPROXY, GOROOT, GOSUMDB, HOME, HOMEBREW_BOTTLE_DOMAIN, LANG, LC_CTYPE, LESS, LOGNAME, LSCOLORS, MML_HOME, NVM_BIN, NVM_CD_FLAGS, NVM_DIR, OLDPWD, OPENCV_PATH, PAGER, PATH, PWD, PYTHONPATH, RUSTUP_DIST_SERVER, RUSTUP_UPDATE_ROOT, SHELL, SHLVL, SSH_AUTH_SOCK, TERM, TERM_PROGRAM, TERM_PROGRAM_VERSION, TERM_SESSION_ID, TMPDIR, USER, XPC_FLAGS, XPC_SERVICE_NAME, ZSH, _
              Go Version: go1.21.3
              Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
               Log Level:
                   Mlock: supported: false, enabled: false
           Recovery Mode: false
                 Storage: inmem
                 Version: Vault v1.15.1, built 2023-10-20T19:16:11Z
             Version Sha: b94e275f25ccd9011146d14c00ea9e49fd5032dc

==> Vault server started! Log data will stream in below:

2023-11-06T10:25:37.723+0800 [INFO]  proxy environment: http_proxy="" https_proxy="" no_proxy=""
2023-11-06T10:25:37.727+0800 [INFO]  incrementing seal generation: generation=1
2023-11-06T10:25:37.727+0800 [WARN]  no `api_addr` value specified in config or in VAULT_API_ADDR; falling back to detection if possible, but this value should be manually set
2023-11-06T10:25:37.733+0800 [INFO]  core: Initializing version history cache for core
2023-11-06T10:25:37.734+0800 [INFO]  events: Starting event system
2023-11-06T10:25:37.736+0800 [INFO]  core: security barrier not initialized
2023-11-06T10:25:37.737+0800 [INFO]  core: security barrier initialized: stored=1 shares=1 threshold=1
2023-11-06T10:25:37.744+0800 [INFO]  core: post-unseal setup starting
2023-11-06T10:25:37.758+0800 [INFO]  core: loaded wrapping token key
2023-11-06T10:25:37.758+0800 [INFO]  core: successfully setup plugin runtime catalog
2023-11-06T10:25:37.758+0800 [INFO]  core: successfully setup plugin catalog: plugin-directory=""
2023-11-06T10:25:37.760+0800 [INFO]  core: no mounts; adding default mount table
2023-11-06T10:25:37.765+0800 [INFO]  core: successfully mounted: type=cubbyhole version="v1.15.1+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: "
2023-11-06T10:25:37.774+0800 [INFO]  core: successfully mounted: type=system version="v1.15.1+builtin.vault" path=sys/ namespace="ID: root. Path: "
2023-11-06T10:25:37.777+0800 [INFO]  core: successfully mounted: type=identity version="v1.15.1+builtin.vault" path=identity/ namespace="ID: root. Path: "
2023-11-06T10:25:37.783+0800 [INFO]  core: successfully mounted: type=token version="v1.15.1+builtin.vault" path=token/ namespace="ID: root. Path: "
2023-11-06T10:25:37.785+0800 [INFO]  rollback: Starting the rollback manager with 256 workers
2023-11-06T10:25:37.787+0800 [INFO]  rollback: starting rollback manager
2023-11-06T10:25:37.789+0800 [INFO]  core: restoring leases
2023-11-06T10:25:37.791+0800 [INFO]  identity: entities restored
2023-11-06T10:25:37.791+0800 [INFO]  identity: groups restored
2023-11-06T10:25:37.791+0800 [INFO]  expiration: lease restore complete
2023-11-06T10:25:37.793+0800 [INFO]  core: Recorded vault version: vault version=1.15.1 upgrade time="2023-11-06 02:25:37.793171 +0000 UTC" build date=2023-10-20T19:16:11Z
2023-11-06T22:25:38.367+0800 [INFO]  core: post-unseal setup complete
2023-11-06T22:25:38.368+0800 [INFO]  core: root token generated
2023-11-06T22:25:38.368+0800 [INFO]  core: pre-seal teardown starting
2023-11-06T22:25:38.369+0800 [INFO]  rollback: stopping rollback manager
2023-11-06T22:25:38.369+0800 [INFO]  core: pre-seal teardown complete
2023-11-06T22:25:38.370+0800 [INFO]  core.cluster-listener.tcp: starting listener: listener_address=127.0.0.1:8201
2023-11-06T22:25:38.370+0800 [INFO]  core.cluster-listener: serving cluster requests: cluster_listen_address=127.0.0.1:8201
2023-11-06T22:25:38.371+0800 [INFO]  core: post-unseal setup starting
2023-11-06T22:25:38.371+0800 [INFO]  core: loaded wrapping token key
2023-11-06T22:25:38.371+0800 [INFO]  core: successfully setup plugin runtime catalog
2023-11-06T22:25:38.371+0800 [INFO]  core: successfully setup plugin catalog: plugin-directory=""
2023-11-06T22:25:38.372+0800 [INFO]  core: successfully mounted: type=system version="v1.15.1+builtin.vault" path=sys/ namespace="ID: root. Path: "
2023-11-06T22:25:38.372+0800 [INFO]  core: successfully mounted: type=identity version="v1.15.1+builtin.vault" path=identity/ namespace="ID: root. Path: "
2023-11-06T22:25:38.372+0800 [INFO]  core: successfully mounted: type=cubbyhole version="v1.15.1+builtin.vault" path=cubbyhole/ namespace="ID: root. Path: "
2023-11-06T22:25:38.373+0800 [INFO]  core: successfully mounted: type=token version="v1.15.1+builtin.vault" path=token/ namespace="ID: root. Path: "
2023-11-06T22:25:38.373+0800 [INFO]  rollback: Starting the rollback manager with 256 workers
2023-11-06T22:25:38.373+0800 [INFO]  rollback: starting rollback manager
2023-11-06T22:25:38.374+0800 [INFO]  core: restoring leases
2023-11-06T22:25:38.374+0800 [INFO]  expiration: lease restore complete
2023-11-06T22:25:38.374+0800 [INFO]  identity: entities restored
2023-11-06T22:25:38.374+0800 [INFO]  identity: groups restored
2023-11-06T22:25:38.374+0800 [INFO]  core: post-unseal setup complete
2023-11-06T22:25:38.374+0800 [INFO]  core: vault is unsealed
2023-11-06T22:25:38.386+0800 [INFO]  core: successful mount: namespace="" path=secret/ type=kv version=""
WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory
and starts unsealed with a single unseal key. The root token is already
authenticated to the CLI, so you can immediately begin using Vault.

You may need to set the following environment variables:

    $ export VAULT_ADDR='http://127.0.0.1:8200'

The unseal key and root token are displayed below in case you want to
seal/unseal the Vault or re-authenticate.

Unseal Key: KiF1ohtchsOjr4IvzHY38/OAPOqS1/rARczTFG6Ull8=
Root Token: hvs.9QOJsa7zlwHO8ieW15CXXoOp

Development mode should NOT be used in production installations!

我们看到dev模式下,Vault server是自动unseal的,并打印出了Unseal Key和Root Token,而且显式地告诉你:所有机密数据都是存储在内存中的,不要将这个模式用于生产环境

前面说过,vault程序继承了Hashicorp产品的基因,它既可以用来启动server,其自身也是一个命令行程序,我们可以用vault命令查看启动的server的状态:

$vault status
Error checking seal status: Get "https://127.0.0.1:8200/v1/sys/seal-status": http: server gave HTTP response to HTTPS client

我们看到:获取vault server状态的命令执行失败,因为我们并没有开启vault server的https端口,仅使用了http端口。我们设置一下环境变量后,再执行status命令:

$export VAULT_ADDR='http://127.0.0.1:8200' // 设置vault server addr为http非安全方式
$vault status
Key             Value
---             -----
Seal Type       shamir
Initialized     true
Sealed          false
Total Shares    1
Threshold       1
Version         1.15.1
Build Date      2023-10-20T19:16:11Z
Storage Type    inmem
Cluster Name    vault-cluster-23f54192
Cluster ID      a86c14e2-b88c-5391-e8b4-0b1b9e9a9aaf
HA Enabled      false

接下来,我们试着向Vault写入一个机密信息。Vault支持多种secret engine,比如:Key/Value secrets engineVersioned Key/value secrets engine(k/v引擎的v2版本)LDAP secrets engineAzure secrets engine等,其中K/V引擎以及带版本的K/V引擎是最常用的。

注:Vault还支持开发者自定义secret engine

我们尝试使用kv子命令向vault中写入一个key/value,放到secret路径下(在dev模式下,secret路径下自动开启v2版本引擎),key为hello,值为foo=world:

$vault kv put -mount=secret hello foo=world
Error making API request.

URL: GET http://127.0.0.1:8200/v1/sys/internal/ui/mounts/secret
Code: 403. Errors:

* permission denied

我们看到命令执行失败,提示没有权限。vault server要求每个访问请求都必须带上token,我们可以使用vault server启动时打印的root token,可以使用环境变量的方式将token注入:

export VAULT_TOKEN="hvs.9QOJsa7zlwHO8ieW15CXXoOp"

也可以执行下面命令并输入root token完成登录:

$vault login
Token (will be hidden):
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                  Value
---                  -----
token                hvs.9QOJsa7zlwHO8ieW15CXXoOp
token_accessor       170OHOscEZjfl8fSa8aVpNkZ
token_duration       ∞
token_renewable      false
token_policies       ["root"]
identity_policies    []
policies             ["root"]

之后,root token就被放置在“~/.vault-token”中了:

$cat ~/.vault-token
hvs.9QOJsa7zlwHO8ieW15CXXoOp

注:我们通常不会使用root token,而是会利用vault token命令生成新token作为vault cli访问vault server的token。

现在我们重新执行一下kv put命令:

$vault kv put -mount=secret hello foo=world
== Secret Path ==
secret/data/hello

======= Metadata =======
Key                Value
---                -----
created_time       2023-11-06T03:01:25.968883Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            2

kv创建成功,路径secret/data/hello(注:vault会默认在mount的路径secret下创建data路径)。vault server在将value值存储在backend storage(这里是memory)前,会用Encryption Key对内容进行加密。如果你多执行几次这个命令,你会发现输出信息中的version的数值会递增,这个数值表示设置的值的版本。

我们可以用kv get获取刚才写入的kv值,vault会将数据从backend storage中读取出来并解密:

$vault kv get -mount=secret hello
== Secret Path ==
secret/data/hello

======= Metadata =======
Key                Value
---                -----
created_time       2023-11-06T03:01:25.968883Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            2

=== Data ===
Key    Value
---    -----
foo    world

我们还可以通过delete删除刚刚建立的kv值(为后面的基本场景示例做铺垫):

$vault kv delete secret/foo
Success! Data deleted (if it existed) at: secret/data/foo
$vault kv get secret/foo
No value found at secret/data/foo

到这里我们看到,一旦vault安装完毕后,基本使用场景还是蛮简单的,但也仅限于基本使用场景^_^。下面我们再来看看如何通过代码来实现这些基本功能场景。

3.5 使用client SDK与Vault交互

Vault支持各种主流语言的client SDK,其中Vault官方维护了三个:Go、Ruby和C#,其他语言的SDK则是由社区维护。

我们用Go Client SDK来编写一个设置kv和获取kv值的小程序,如下面代码所示:

// secret-management-examples/basic/main.go

package main

import (
    "context"
    "fmt"

    "github.com/hashicorp/vault/api"
)

func main() {
    // 创建一个新的Vault客户端
    client, err := api.NewClient(api.DefaultConfig())
    if err != nil {
        fmt.Println("无法创建Vault客户端:", err)
        return
    }

    // 设置Vault服务器的地址
    client.SetAddress("http://localhost:8200/")

    // 设置Vault的访问令牌(如果需要认证)
    client.SetToken("hvs.9QOJsa7zlwHO8ieW15CXXoOp")

    // 设置要写入的机密信息
    secretData := map[string]interface{}{
        "foo": "bar",
    }

    kv2 := client.KVv2("secret") // mount "secret"

    // 写入机密信息到Vault的secret/data/{key}路径下
    key := "hello"
    _, err = kv2.Put(context.Background(), key, secretData)
    if err != nil {
        fmt.Println("无法写入机密信息:", err)
        return
    }

    // 读取Vault的secret/data/{key}路径下的机密信息
    secret, err := kv2.Get(context.Background(), key)
    if err != nil {
        fmt.Println("无法读取机密信息:", err)
        return
    }

    // 打印读取到的值
    fmt.Println("读取到的值:", secret.Data)
}

我们看到:默认创建的api.Client操作的都是v1版本的数据,这里通过KVv2方法将其转换为可以操作v2版本数据的client,之后put和get就可以如预期正常工作了!

下面是其运行结果:

$go run main.go
读取到的值: map[foo:bar]

有了基础场景做铺垫,接下来我们就进入实例环节,看看应用是如何基于Vault应对一些常见的机密管理场景的。

4. 常见的机密管理场景

Vault支持对多种机密信息的管理,包括应用访问外部服务或资源所需的用户名/密码、API密钥或访问令牌(token),应用程序的配置中的机密配置信息,比如数据库连接字符串、加密密钥等,以及私钥、证书等加密相关的机密信息等。这里我们就分别来看看应用与Vault集成并获取这些机密信息的场景,不过在这之前,我们首先需要先来了解一下应用本身与Vault是如何集成的。

4.1 应用通过Vault身份认证和授权的方法

在3.5小节的基本场景示例中,我们的client使用了一个长期有效的token通过了Vault的身份认证和授权环节,拥有了操作Vault数据的权限。

token auth方法也是dev模式下Vault server实例支持的唯一auth method,我们可以通过auth list命令查看vault server当前支持的auth方法集合:

$vault auth list
Path      Type     Accessor               Description                Version
----      ----     --------               -----------                -------
token/    token    auth_token_6f9cc41c    token based credentials    n/a

不过,基于token来实现app与Vault的集成并非Vault官方推荐的在生产环境使用的auth方式,理由也很明显:这种方式涉及手动创建一个长期有效的令牌,这有悖于最佳实践,并存在安全风险。

除了Token auth method,Vault还支持AppRoleJWT/OIDCTLS证书以及User/Password多种auth method,这些auth method的共同之处在于通过身份认证后,Vault可自动创建短期令牌供客户端使用,无需定期手动生成新令牌,短期令牌可以减少令牌泄露的风险,因为短期令牌在一定时间后会自动失效,并需要重新进行身份认证。

简单起见,我这里就用User/Password method作为实例演示一下应用通过Vault的身份认证和授权。

我们先来开启(enable)基于User/Password的auth method:

$vault auth enable userpass
Success! Enabled userpass auth method at: userpass/

该命令默认将会启用auth/userpass路径,之后通过auth list查看,就能在list中看到新增的userpass auth method了:

$vault auth list
Path         Type        Accessor                  Description                Version
----         ----        --------                  -----------                -------
token/       token       auth_token_6f9cc41c       token based credentials    n/a
userpass/    userpass    auth_userpass_b5b6e974    n/a                        n/a

接下来,我们在vault服务实例中建立一个新的user:

$vault write auth/userpass/users/tonybai password=ilovegolang
Success! Data written to: auth/userpass/users/tonybai

$vault read auth/userpass/users/tonybai
Key                        Value
---                        -----
token_bound_cidrs          []
token_explicit_max_ttl     0s
token_max_ttl              0s
token_no_default_policy    false
token_num_uses             0
token_period               0s
token_policies             [default]
token_ttl                  0s
token_type                 default

下面是示例代码:

// secret-management-examples/auth_user_password/main.go

package main

import (
    "context"
    "fmt"

    "github.com/hashicorp/vault/api"
    auth "github.com/hashicorp/vault/api/auth/userpass"
)

func main() {
    user := "tonybai"
    pass := "ilovegolang"

    // 创建Vault API客户端
    client, err := api.NewClient(api.DefaultConfig())
    if err != nil {
        fmt.Printf("无法创建Vault客户端: %v\n", err)
        return
    }
    // 设置 Vault 地址
    client.SetAddress("http://localhost:8200")

    // client登录vault服务器获取临时访问令牌
    userpassAuth, err := auth.NewUserpassAuth(user, &auth.Password{FromString: pass})
    if err != nil {
        fmt.Errorf("无法初始化userpass auth method: %w", err)
        return
    }

    secret, err := client.Auth().Login(context.Background(), userpassAuth)
    if err != nil {
        fmt.Errorf("登录Vault失败: %w", err)
        return
    }
    if secret == nil {
        fmt.Printf("登录后没有secret信息返回: %v\n", err)
        return
    }
    fmt.Printf("登录Vault成功\n")

    token := secret.Auth.ClientToken

    // 设置临时访问令牌
    client.SetToken(token)

    kv2 := client.KVv2("secret") // mount "secret"
    // 读取Vault的secret/data/{key}路径下的机密信息
    data, err := kv2.Get(context.Background(), "hello")
    if err != nil {
        fmt.Println("无法读取机密信息:", err)
        return
    }

    // 打印读取到的值
    fmt.Println("读取到的值:", data.Data)
}

如果你在Vault的GO SDK中没有找到对user/password auth method的直接支持,你也可以参考user/password auth method的API文档自行实现登录Vault并读取特定机密信息,代码如下(与上面代码功能是等价的):

// secret-management-examples/auth_user_password_self_impl/main.go

func clientAuth(vaultAddr, user, pass string) (*api.Secret, error) {
    payload := fmt.Sprintf(`{"password": "%s"}`, pass)

    req, err := http.NewRequest("POST", vaultAddr+"/v1/auth/userpass/login/"+user, strings.NewReader(payload))
    if err != nil {
        return nil, err
    }

    resp, err := http.DefaultClient.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        return nil, err
    }

    if resp.StatusCode != http.StatusOK {
        return nil, errors.New(string(body))
    }

    return api.ParseSecret(bytes.NewReader(body))
}

func main() {
    vaultAddr := "http://localhost:8200"
    user := "tonybai"
    pass := "ilovegolang"

    // client登录vault服务器获取临时访问令牌
    secret, err := clientAuth(vaultAddr, user, pass)
    if err != nil {
        fmt.Printf("登录Vault失败: %v\n", err)
        return
    }
    fmt.Printf("登录Vault成功\n")

    // 创建Vault API客户端
    client, err := api.NewClient(api.DefaultConfig())
    if err != nil {
        fmt.Printf("无法创建Vault客户端: %v\n", err)
        return
    }

    // 设置 Vault 地址
    client.SetAddress("http://localhost:8200")
    token := secret.Auth.ClientToken

    // 设置临时访问令牌
    client.SetToken(token)

    kv2 := client.KVv2("secret") // mount "secret"
    // 读取Vault的secret/data/{key}路径下的机密信息
    data, err := kv2.Get(context.Background(), "hello")
    if err != nil {
        fmt.Println("无法读取机密信息:", err)
        return
    }

    // 打印读取到的值
    fmt.Println("读取到的值:", data.Data)
}

我们运行一下上述两个示例代码之一:

$go run main.go
登录Vault成功
无法读取机密信息: error encountered while reading secret at secret/data/hello: Error making API request.

URL: GET http://localhost:8200/v1/secret/data/hello
Code: 403. Errors:

* 1 error occurred:
    * permission denied

通过错误信息来看,“tonybai”这个user没有权限读取secret/data/hello下的机密信息!那么怎么给这个用户加上secret/data/hello的读取权限呢?Vault通过policy来管理权限,如果某个user具有某个policy的绑定,那么该user就拥有该policy设定的权限,这有点像RBAC的思路,只是没有引入role的概念! 我们先来添加一个拥有secret/data/hello读权限的policy:

$vault policy write my-policy -<<EOF
# Allow "read" permission on "secret/data/*" secrets
path "secret/data/*" {
  capabilities = ["read"]
}
EOF
Success! Uploaded policy: my-policy

接下来重写user的属性数据,将my-policy赋给”tonybai”这个user:

$vault write auth/userpass/users/tonybai password=ilovegolang token_policies=my-policy
Success! Data written to: auth/userpass/users/tonybai

$vault read auth/userpass/users/tonybai
Key                        Value
---                        -----
token_bound_cidrs          []
token_explicit_max_ttl     0s
token_max_ttl              0s
token_no_default_policy    false
token_num_uses             0
token_period               0s
token_policies             [my-policy]
token_ttl                  0s
token_type                 default

完成上述设置后,我们再来运行一下基于user/password auth method的程序:

$go run main.go
登录Vault成功
读取到的值: map[foo:bar]

这次程序成功登录Vault并成功读取了secret/data/hello下面的机密数据。

这里我们除了设置了token_policies,其他属性都保持了默认值,这样我们拿到的临时token其实并不“临时”,我们可以一直使用。下面我们通过设置token_ttl来指定每个临时token的最大有效时间:

$vault write auth/userpass/users/tonybai password=ilovegolang token_policies=my-policy token_ttl=5s
Success! Data written to: auth/userpass/users/tonybai

$vault read auth/userpass/users/tonybai
Key                        Value
---                        -----
token_bound_cidrs          []
token_explicit_max_ttl     0s
token_max_ttl              0s
token_no_default_policy    false
token_num_uses             0
token_period               0s
token_policies             [my-policy]
token_ttl                  5s
token_type                 default

我们改写一下程序,让程序每隔1秒用临时token获取一下机密信息并输出:

// secret-management-examples/auth_user_password_renewal/main.go (临时版本)

    for {
        // 每个一秒读取一次Vault的secret/data/{key}路径下的机密信息
        data, err := kv2.Get(context.Background(), "hello")
        if err != nil {
            fmt.Println("无法读取机密信息:", err)
            return
        }

        // 打印读取到的值
        log.Println("读取到的值:", data.Data)
        time.Sleep(time.Second)
    }

我们运行这个程序将得到如下结果:

$go run main.go
登录Vault成功
2023/11/06 05:24:17 读取到的值: map[foo:bar]
2023/11/06 05:24:18 读取到的值: map[foo:bar]
2023/11/06 05:24:19 读取到的值: map[foo:bar]
2023/11/06 05:24:20 读取到的值: map[foo:bar]
2023/11/06 05:24:21 读取到的值: map[foo:bar]
无法读取机密信息: error encountered while reading secret at secret/data/hello: Error making API request.

URL: GET http://localhost:8200/v1/secret/data/hello
Code: 403. Errors:

* permission denied

我们看到如果token过期,而我们的程序又没有对token进行续期(renewal),程序后续对Vault中机密数据的访问将以”permission denied”的失败而告终。下面我们就来为程序加上token续期,Vault SDK提供了LifetimeWatcher来辅助token续期工作,下面就是利用LifetimeWatcher进行token续期的示例:

// secret-management-examples/auth_user_password_renewal/main.go

package main

import (
    "context"
    "fmt"
    "log"
    "time"

    "github.com/hashicorp/vault/api"
    auth "github.com/hashicorp/vault/api/auth/userpass"
)

func main() {
    user := "tonybai"
    pass := "ilovegolang"

    // 创建Vault API客户端
    client, err := api.NewClient(api.DefaultConfig())
    if err != nil {
        fmt.Printf("无法创建Vault客户端: %v\n", err)
        return
    }
    // 设置 Vault 地址
    client.SetAddress("http://localhost:8200")

    // client登录vault服务器获取临时访问令牌
    userpassAuth, err := auth.NewUserpassAuth(user, &auth.Password{FromString: pass})
    if err != nil {
        fmt.Errorf("无法初始化userpass auth method: %w", err)
        return
    }

    secret, err := client.Auth().Login(context.Background(), userpassAuth)
    if err != nil {
        fmt.Errorf("登录Vault失败: %w", err)
        return
    }
    if secret == nil {
        fmt.Printf("登录后没有secret信息返回: %v\n", err)
        return
    }
    fmt.Printf("登录Vault成功\n")

    token := secret.Auth.ClientToken

    // 设置临时访问令牌
    client.SetToken(token)

    // 设置renewel watcher
    watcher, err := client.NewLifetimeWatcher(&api.LifetimeWatcherInput{
        Secret: secret,
    })
    go watcher.Start()
    defer watcher.Stop()

    kv2 := client.KVv2("secret") // mount "secret"
    ticker := time.NewTicker(time.Second)

    for {
        select {
        case err := <-watcher.DoneCh():
            if err != nil {
                log.Printf("Failed to renew token: %v. Re-attempting login.", err)
                return
            }

            // This occurs once the token has reached max TTL.
            log.Printf("Token can no longer be renewed. Re-attempting login.")
            return

        case renewal := <-watcher.RenewCh():
            // Renewal is now over
            log.Printf("Successfully renewed: %#v", renewal)

        case <-ticker.C:
            // 每个一秒读取一次Vault的secret/data/{key}路径下的机密信息
            data, err := kv2.Get(context.Background(), "hello")
            if err != nil {
                fmt.Println("无法读取机密信息:", err)
                continue
            }
            // 打印读取到的值
            log.Println("读取到的值:", data.Data)
        }
    }
}

运行上述示例(此时token_ttl为5s):

$go run main.go
登录Vault成功
2023/11/06 05:17:42 Successfully renewed: &api.RenewOutput{RenewedAt:time.Date(2023, time.November, 7, 14, 17, 42, 233750000, time.UTC), Secret:(*api.Secret)(0xc000114a80)}
2023/11/06 05:17:43 读取到的值: map[foo:bar]
2023/11/06 05:17:44 读取到的值: map[foo:bar]
2023/11/06 05:17:45 读取到的值: map[foo:bar]
2023/11/06 05:17:45 Successfully renewed: &api.RenewOutput{RenewedAt:time.Date(2023, time.November, 7, 14, 17, 45, 841374000, time.UTC), Secret:(*api.Secret)(0xc0002827e0)}
2023/11/06 05:17:46 读取到的值: map[foo:bar]
2023/11/06 05:17:47 读取到的值: map[foo:bar]
2023/11/06 05:17:48 读取到的值: map[foo:bar]
2023/11/06 05:17:49 读取到的值: map[foo:bar]
2023/11/06 05:17:49 Successfully renewed: &api.RenewOutput{RenewedAt:time.Date(2023, time.November, 7, 14, 17, 49, 443211000, time.UTC), Secret:(*api.Secret)(0xc0002831a0)}
2023/11/06 05:17:50 读取到的值: map[foo:bar]
2023/11/06 05:17:51 读取到的值: map[foo:bar]
2023/11/06 05:17:52 读取到的值: map[foo:bar]
2023/11/06 05:17:53 Successfully renewed: &api.RenewOutput{RenewedAt:time.Date(2023, time.November, 7, 14, 17, 53, 46880000, time.UTC), Secret:(*api.Secret)(0xc000115a40)}
2023/11/06 05:17:53 读取到的值: map[foo:bar]
2023/11/06 05:17:54 读取到的值: map[foo:bar]
... ...

我们看到,在token过期之前,LifetimeWatcher帮助Client完成了续期请求。LifetimeWatcher运行在一个单独的goroutine中,通过channel与main goroutine通信。Vault默认token_max_ttl的值为32天,即便你没有设置其值,当token续期到32天时,就无法再renew了,此时watcher.DoneCh会返回事件,这是让你重新login的信号,示例中只给出了注释,并未重新login,大家注意一下。出于安全考虑,可以将token_max_ttl设置为一个合理的值,使其起到应有的安全作用。

通过这个示例我们看到,只要通过Vault的身份认证和授权,我们就能安全地存储和使用机密信息了。那么如何保证应用在与Vault进行身份认证和授权时所使用的凭据的安全呢?比如上面程序里所需的user和password。这个感觉又回到“先有鸡还是先有蛋”的问题了!实际在生产环境,我们可以依赖IaaS层或公有云的安全措施来保证,比如通过环境变量在运行时注入user和password;再比如利用公有云提供的KMS(key management system)或HSM(Hardware Security Module)服务来保证user和password安全。

4.2 静态secret

将静态secret作为机密信息保存和管理,是Vault非常常见的应用。secret可以存在很长时间不变,或可能很少改变。Vault可以使用它的加密屏障(barrier)存储这些secret,应用程序运行时可以向Vault请求读取这些secret来使用。

Vault的versioned secrets engine支持你以安全的方式存储和管理secret,同时还提供secret的版本控制能力。你可以使用不同版本的secret进行应用程序升级或回滚,也可以在需要时轻松地恢复旧版本secret。引擎还可以记录secret每个版本的修改人和修改时间。

关于静态secret的管理和使用,可以参见3.5中的基本场景,这里就不赘述了。

4.3 动态secret

有静态、长有效期的静态secret,就会有对应的动态secret。和静态secret相比,动态secret安全性高,每个动态secret的有效期都较短,并且一旦泄露可以马上撤销,同时动态secret也便于轮换,定期自动过期无需中断业务。

Vault提供了对多种针对不同系统的动态secret管理能力,包括数据库访问凭据、Active Directory账号, SSH keys和PKI certificates ,Vault针对不同系统提供了不同的secret engine。

Vault官方举了一个有关使用Database Secrets Engine实现数据库动态secret的示例,

鉴于篇幅,这里也不细说了。

4.4 其他场景

根据Vault官方文档对Vault应用场景的描述,除了静态和动态secret类机密信息,Vault可以处理以下类型的机密信息:

  • 数据加密类(Data encryption)机密信息

Vault支持将数据加密服务外包给Vault,应用只需关注数据的加密与解密,Vault负责核心密钥和加密管理。Vault还支持对数据进行传输加密与存储加密。

  • 身份识别类(Identity-Based access)机密信息

Vault支持从不同身份验证系统整合用户身份,实现统一的ACL系统,管理对系统和应用的访问。

  • 加密密钥类(Key management)机密信息

Vault支持对云提供商密钥的生命周期管理,例如管理AWS KMS或GCP云密钥。

鉴于篇幅和实验环境有限,这里就针对每种情况做详细示例说明了,大家可以根据自己的需求,针对具体的某个场景做专题性的研究。

5. 小结

本文首先介绍了机密管理的概念,阐述了在现代Web应用开发中,为何需要重视机密管理。

接着,文中概述了专用于实现机密管理的机密管理系统的发展历程,以及从功能上逐步演化出的云原生机密管理系统的特征。

文章以业内知名的开源机密管理系统HashiCorp Vault为例,全面系统地介绍了它的架构设计、安全模型、使用方法,并详细阐释了应用程序如何通过与Vault API/SDK的集成,实现对各类机密信息的安全存储、动态生成、访问控制、审计等功能。

最后,文章用代码实例详细演示了基于Vault的几个典型机密管理场景,如不同类型机密信息的读写操作,以及不同认证方式的集成等。

这是个”每个人都应该重视安全的时代”,安全需要每个环节的参与,一处薄弱,就会导致“处处薄弱”。我相信本文的内容能有助于让大家对机密管理的概念、重要性及具体实现方法有更深入的理解。

本文涉及的代码可以在这里下载。

注:Vault项目还提供了Vault Agent和Vault Proxy,旨在为应用提供更可扩展、更简单的方式来集成Vault,消除应用程序采用Vault的初期障碍。Vault Agent可以获取secrets并将它们提供给应用程序,Vault Proxy可以在Vault和应用程序之间充当代理,可选地简化认证过程并缓存请求。有兴趣的童鞋可以参考Vault Agent和Proxy的官方文档

6. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

通过实例理解Go Web身份认证的几种方式

本文永久链接 – https://tonybai.com/2023/10/23/understand-go-web-authn-by-example

2023年Q1 Go官方用户调查报告中,API/RPC services、Websites/web services都位于使用Go开发的应用类别的头部(如下图):

我个人使用Go开发已很多年,但一直从事底层基础设施、分布式中间件等方向,Web应用开发领域涉及较少,像Web应用领域常见的CRUD更是少有涉猎,不能不说是一种“遗憾”^_^。未来一段时间,团队会接触到Web应用的开发,我打算对Go Web应用开发的重点环节做一个快速系统的梳理。

而身份认证(Authentication,简称AuthN)是Web应用开发中一个关键的环节,也是首个环节,它负责验证用户身份,让用户可以以认证过的身份访问系统中的资源和信息。

Go语言作为一门优秀的Web开发语言,提供了丰富的机制来实现Web应用的用户身份认证。在这篇文章中,我就通过Go示例和大家一起探讨一下当前Web应用开发中几种常见的主流身份认证方式,帮助自己和各位读者迈出Web应用开发修炼之路的第一步

1. 身份认证简介

1.1 身份认证解决的问题

身份认证不局限于Web应用,各种系统都会有身份认证,但本文我们聚焦Web应用领域的身份认证技术。

几乎所有Web应用的安全性都是从身份认证开始的,身份认证是验证用户身份真实性的过程,是我们首先要部署的策略。位于下游的安全控制,如授权(Authorization, AuthZ)、审计日志(Audit log)等,几乎都需要用户的身份。

身份认证的英文是Authentication,简写为AuthN,大家不要将之与授权Authorization(AuthZ)混淆(在后续系列文章中会继续探讨AuthZ相关的内容),他们所要解决的问题相似,但有不同,也有先后。通常先AuthN,再AuthZ。我们可以用下面的比喻来形象地解释二者的联系与差异:

  • AuthN就像是进入公司大楼的安检,负责检查员工的身份是否合法,是否具有进入公司的资格,它解决的是验证员工身份的问题
  • AuthZ更像是公司内部的权限管理,某个员工进入了公司后(AuthN后)想访问一些重要资料,这时还需要确认该员工是否有相应的访问权限。它解决的是授权访问控制的问题。

简单来说,AuthN是验证你是谁,authZ是验证你有哪些权限。AuthN解决认证问题,AuthZ解决授权问题,这两个都重要,AuthN解决外部的安全问题,authZ解决内部的安全与合规问题。

1.2 身份认证的三要素

身份认证需要被认证方提供一些身份信息输入,这些代表身份信息的输入被称为身份认证要素(authentication factor)。这些要素有很多,大致可分为三类:

  • 你知道的东西(What you know)

即基于被认证方知道的特定信息来验证身份,最常见的如密码等。

  • 你拥有的东西(What you have)

基于被认证方所拥有的特定物件来验证身份,最常见的利用数字证书、令牌卡等。N年前,在移动端应用还没有发展起来时,一些人在银行办理电子银行业务时会拿到一个U盾(又称为USBKey),其中存放着用于用户身份识别的数字证书,这个U盾就属于此类要素。

上面比喻中进入大楼时使用的员工卡也属于这类要素。

  • 你本身就具有的(What you are)

即基于被认证方所拥有的生物特征要素(biometric factor)来验证身份,最常见的人脸识别、指纹/声纹/虹膜识别和解锁等。理论上来说,具备个人生物特征的身份认证标志具有不可仿冒性、唯一性。

如果上面比喻中的大楼已经开启了人脸识别功能,那么基于人脸识别的认证就属于这类要素的认证。

通常我们会基于单个要素设计身份认证方案,一旦使用两个或两个以上不同类的要素,就可以被称为双因素认证(2FA)多因素认证(MFA)了。不过,2FA和MFA都比较复杂,不再本篇文章讨论范围之内。

基于上述要素,我们就可以设计和实现各种适合不同类别Web应用或API服务的身份认证方法了。Web应用和API服务都需要身份认证,它们有什么差异呢?这些差异是否会对身份认证方案产生影响呢?我们接下来看一下。

1.3 Web应用身份认证 vs. API服务身份认证

Web应用和API服务主要有以下几点区别:

  • 交互方式不同

Web应用是浏览器与服务器之间的交互,用户通过浏览器访问Web应用。而API服务是程序/应用与服务器之间的交互,通过API请求获取数据或执行操作。

  • 返回数据格式不同

Web应用通常会返回html/js/css等浏览器可解析执行的代码,而API服务通常返回结构化数据,常见的如JSON或XML等。

  • 使用场景不同

Web应用主要面向人类用户的使用,用户通过浏览器进行操作。而API服务主要被其他程序调用,为程序之间提供接口与数据支撑。

  • 状态管理不同

Web应用在服务端保存会话状态,浏览器通过cookie等保存用户状态。而API服务通常是无状态的,每次请求都需要携带用于身份认证的信息,比如访问令牌或API Key等。

  • 安全方面的关注点不同

Web应用更关注XSSCSRF等输入验证安全,而API服务更关注身份认证(authN)、授权(authZ)、准入(admission)、限流等访问控制安全。

总之,Web应用注重界面的展示和用户交互;而API服务注重数据和服务的提供,它们有不同的使用场景、交互方式和安全关注点。

Web应用和API服务的这些差异也导致了Web应用和API服务适合使用的身份认证方案上会有所不同。但前后端分离架构的出现和普及,让前后端责任分离:前端专注于视图和交互,后端专注数据和业务,并且前后端通过标准化的API接口进行数据交互。这可以让后端提供统一的认证接口,不同的前端可以共享。像基于Token这样的无状态易理解的身份验证机制逐渐成为主流。也就是说,架构模式的变化,使得Web应用和API服务在身份验证(authN)方案上出现了一些融合的现象,因此在身份认证方法上,Web应用和API服务也存在一些交集。

下面维韦恩图列出了三类身份认证方法,包括仅适用于Web应用的、仅适用于API服务的以及两者都适用的:

本文聚焦Web应用的身份认证方式,接下来会重点说说上图中绿色背景色的几种身份认证方式。

2. 安全信道是身份认证的前提和基础

在对具体的Web身份认证方式进行说明之前,我们先来了解一下身份认证的前提和基础 – 安全信道

在Web应用身份认证的过程中,无论采用何种认证方式,用户的身份要素信息(用户名/密码、token、生物特征信息)都要传递给服务器,这时候如果传递此类信息的通信信道不安全,这些重要的认证要素信息就很容易被中间人截取、破解、篡改并被冒充,从而获得Web应用的使用权。从服务端角度来看,如果没有安全信道,服务器身份也容易被伪装,导致用户连接到“冒牌服务器”并导致严重后果。因此,没有建立在安全信道上的身份认证是不安全,不具备实际应用价值的,甚至是完全没有意义的。

此外,安全信道不仅对登录阶段的身份认证环节有重要意义,在用户已登录并访问Web应用其他功能页面时,安全通道也可以对数据的传输以及类似访问令牌或Cookie数据的传输起到加密和保护作用。

在Web应用领域,最常用的安全信道建立方式是基于HTTPS(HTTP over TLS)或直接建立在TLS之上的自定义通信,TLS利用证书对通信进行加密、验证服务器身份(甚至是客户端身份的验证),保障信息的机密性和完整性。各大安全规范和标准如PCI DSS(Payment Card Industry Data Security Standard)OWASP也强制要求使用HTTPS保障认证安全。

基于安全信道,我们还可以实施第一波的身份认证,这就是我们通常所说的基于HTTPS(或TLS)的双向身份认证

注:在我的《Go语言精进之路vol2》一书中,对TLS的机制以及基于Go标准库的TLS的双向认证有系统全面的说明,欢迎各位童鞋阅读反馈。

这种认证方式采用的是身份认证要素中的第二类要素:What you have。客户端带着归属于自己的专有证书去服务端做身份验证。如果client证书通过服务端的验签后,便可允许client进入“大楼”。

下面是一个基于TLS证书做身份认证的客户端与服务端交互的示意图:

我们先看看对应上述示意图中的客户端的代码:

// authn-examples/tls-authn/client/main.go

func main() {

    // 1. 读取客户端证书文件
    clientCert, err := tls.LoadX509KeyPair("client-cert.pem", "client-key.pem")
    if err != nil {
        log.Fatal(err)
    }

    // 2. 读取中间CA证书文件
    caCert, err := os.ReadFile("inter-cert.pem")
    if err != nil {
        log.Fatal(err)
    }
    certPool := x509.NewCertPool()
    certPool.AppendCertsFromPEM(caCert)

    // 3. 发送请求

    client := &http.Client{
        Transport: &http.Transport{
            TLSClientConfig: &tls.Config{
                Certificates: []tls.Certificate{clientCert},
                RootCAs:      certPool,
            },
        },
    }

    req, err := http.NewRequest("GET", "https://server.com:8443", nil)
    if err != nil {
        log.Fatal(err)
    }
    resp, err := client.Do(req)
    if err != nil {
        log.Fatal(err)
    }

    // 4. 打印响应信息
    fmt.Println("Response Status:", resp.Status)
    //  fmt.Println("Response Headers:", resp.Header)
    body, _ := io.ReadAll(resp.Body)
    fmt.Println("Response Body:", string(body))
}

客户端加载client-cert.pem作为后续与服务端通信的身份凭证,加载inter-cert.pem用于校验服务端在tls握手过程发来的服务端证书(server-cert.pem),避免连接到“冒牌站点”。通过验证后,客户端向服务端发起Get请求并输出响应的内容。

下面是服务端的代码:

// authn-examples/tls-authn/server/main.go

func main() {
    var validClients = map[string]struct{}{
        "client.com": struct{}{},
    }

    // 1. 加载证书文件
    cert, err := tls.LoadX509KeyPair("server-cert.pem", "server-key.pem")
    if err != nil {
        log.Fatal(err)
    }

    caCert, err := os.ReadFile("inter-cert.pem")
    if err != nil {
        log.Fatal(err)
    }
    certPool := x509.NewCertPool()
    certPool.AppendCertsFromPEM(caCert)

    // 2. 配置TLS
    tlsConfig := &tls.Config{
        Certificates: []tls.Certificate{cert},
        ClientAuth:   tls.RequireAndVerifyClientCert, // will trigger the invoke of VerifyPeerCertificate
        ClientCAs:    certPool,
    }

    // tls.Config设置
    tlsConfig.VerifyPeerCertificate = func(rawCerts [][]byte, verifiedChains [][]*x509.Certificate) error {
        // 获取客户端证书
        cert := verifiedChains[0][0]

        // 提取CN作为客户端标识
        clientID := cert.Subject.CommonName
        fmt.Println(clientID)

        _, ok := validClients[clientID]
        if !ok {
            return errors.New("invalid client id")
        }

        return nil
    }
    // 添加处理器
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        w.Write([]byte("Hello World!"))
    })

    // 3. 创建服务器
    srv := &http.Server{
        Addr:      ":8443",
        TLSConfig: tlsConfig,
    }

    // 4. 启动服务器
    err = srv.ListenAndServeTLS("", "")
    if err != nil {
        log.Fatal(err)
    }
}

注:在你的实验环境中,需要在/etc/hosts文件中添加server.com的映射ip为127.0.0.1。

服务端代码也不复杂,比较“套路化”:加载服务端证书和中间CA证书(用于验签client端的证书),这里将tls.Config.ClientAuth设置为RequireAndVerifyClientCert,这会触发服务端对客户端证书的验签,同时在tlsConfig.VerifyPeerCertificate不为nil的情况下,触发对tlsConfig.VerifyPeerCertificate的函数的调用,在示例代码中,我们为tlsConfig.VerifyPeerCertificate赋值了一个匿名函数实现,在这个函数中,我们提取了客户端证书中的客户端标识CN,并查看其是否在可信任的客户端ID表中。

在这个示例中,这个tlsConfig.VerifyPeerCertificate执行的验证有些多余,但我们在实际代码中可以使用tlsConfig.VerifyPeerCertificate来设置黑名单,拦截那些尚未过期、但可以验签通过的客户端,实现一种客户端证书过期前的作废机制

此外,上述示例中客户端、服务端以及中间CA证书的制作代码与《Go TLS服务端绑定证书的几种方式》一文中的证书制作很类似,大家可以直接参考本文示例代码中的tls-authn/make-certs下面的代码,这里就不赘述了。

通过这种基于安全信道的身份验证方式,客户端证书可以强制认证用户,理论上不需要额外再用用户名密码。认证之后客户端在这个TLS连接上发送的所有信息都将绑定其身份。

不过通过颁发客户端专用证书的方式仅适合一些像网络银行之类的专有业务,大多数Web应用会与客户端间建立安全信道,但不会采用客户端证书来认证用户身份,在这样的情况下,下面要说的这些身份认证方式就可以发挥作用了。

我们先来看一下最传统的基于密码的认证。

3. 基于密码的认证

基于密码的认证属于基于第一类身份认证要素:你知道的东西(What you know)的认证方式,这类认证也是Web应用中最经典、最常见的认证方式。我们先从基于传统表单承载用户名/密码说起。

3.1. 基于用户名+密码的认证(传统表单方式)

这是最常见的Web应用认证方式:用户通过提交包含用户名和密码的表单(Form),服务端Web应用进行验证。下面使用这种方式的客户端与服务单的交互示意图:

接下来,我们看看对应上述示意图的实现代码。我们先建立一个html文件,该文件非常简单,就是一个可输入用户名和密码的表单,点击登录按钮将表单信息发送到服务端:

// authn-examples/password/classic/login.html

<!DOCTYPE html>
<html>
<head>
  <title>登录</title>
</head>
<body>

<form action="http://server.com:8080/login" method="post">

  <label>用户名:</label>
  <input type="text" name="username"/>

  <label>密码:</label>
  <input type="password" name="password"/>

  <button type="submit">登录</button>

</form>

</body>
</html>

发送的HTTP Post请求的包体(Body)中会包含页面输入的username和password的值,形式如下:

username=admin&password=123456

而我们的服务端的代码如下:

// authn-examples/password/classic/main.go

func main() {
    http.HandleFunc("/login", login)
    http.ListenAndServe(":8080", nil)
}

func login(w http.ResponseWriter, r *http.Request) {
    username := r.FormValue("username")
    password := r.FormValue("password")

    if isValidUser(username, password) {
        w.Write([]byte("Welcome!"))
        return
    }

    http.Error(w, "Invalid username or password", http.StatusUnauthorized) // 401
}

var credentials = map[string]string{
    "admin": "123456",
}

func isValidUser(username, password string) bool {
    // 验证用户名密码
    v, ok := credentials[username]
    if !ok {
        return false
    }

    if v != password {
        return false
    }
    return true
}

服务端通过Request的FormValue方法获得username和password的值,并与credentials存储的合法用户信息比对(当然这只是演示代码中的临时手段,生产中不要这么存储用户信息),比对成功,返回”Welcome”应答;比对失败,返回401 Unauthorized错误。

注:包括本示例在内的后续所有示例的客户端和服务端都在非安全信道上通信,目的是简化示例代码的编写。大家在生产环境务必建立安全信道后再做后续的身份验证。

基于传统的表单用户名和密码可以作为Web应用服务端身份验证的方案,但问题来了:服务端认证成功后,用户后续向Web应用服务端发起的请求是否还要继续带上用户和密码信息呢?如果不带上用户和密码信息,服务端又如何验证这些请求是来自之前已经认证成功后的用户;如果后续每个请求都带上以Form形式承载的用户名和密码,使用起来又非常不方便,还影响后续请求的正常数据的传输(对Body数据有侵入)。

于是便有了Session(会话)机制,它可以被认为是基于经典的用户名密码(表单承载)认证方式的“延续”,使得密码认证的成果不再局限在缺乏连续性的单一请求级别上,而是扩展到后续的一段时间内或一系列与Web应用的互操作过程中,变成了连续、持久的登录会话。

接下来,我们就来简单看看基于Session的后续认证方式是如何工作的。

3.2 使用Session:有状态的认证方式

基于Session的认证方式是一种有状态的方案,服务端会为每个身份认证成功的用户建立并保存相关session信息,同时服务端也会要求客户端在浏览器侧持久化与该Session有关少量信息,通常客户端会通过开启Cookie的方式来保存与用户Session相关的信息。

服务端保存Session有多种方式,可以在进程内存中、文件中、数据库、缓存(Redis)等,不同方式各有优缺点,比如将Session保存在内存中,最大的好处就是实现简单且速度快,但由于不能持久化,服务实例重启后就会丢失,此外当服务端有多副本时,session信息无法在多实例共享;使用关系数据库来保存session,可以方便持久化,也方便与服务端多实例用户数据共享,但数据库交互成本较大;而使用缓存(Redis)存储session信息是目前比较主流的方式,简单、安全、快速,还可以很好地适合分布式环境下session的共享。

下面是一个常见的基于cookie实现的session机制的客户端与服务端的交互示意图:

这里也给出上述示意图的一个参考实现示例(代码仅用作演示,很多值设置并不规范和安全,不要用于生产)。

session机制的开启从用户登录开始,这个示例里的login.html与上一个示例是一样的:

// authn-examples/password/session/login.html

<!DOCTYPE html>
<html>
<head>
  <title>登录</title>
</head>
<body>

<form action="http://server.com:8080/login" method="post">

  <label>用户名:</label>
  <input type="text" name="username"/>

  <label>密码:</label>
  <input type="password" name="password"/>

  <button type="submit">登录</button>

</form>

</body>
</html>

服务端负责的login Handler代码如下:

// authn-examples/password/session/main.go

var store = sessions.NewCookieStore([]byte("session-key"))

func main() {
    http.HandleFunc("/login", login)
    http.HandleFunc("/calc", calc)
    http.HandleFunc("/calcAdd", calcAdd)

    http.ListenAndServe(":8080", nil)
}

var credentials = map[string]string{
    "admin": "123456",
    "test":  "654321",
}

func isValid(username, password string) bool {
    // 验证用户名密码
    v, ok := credentials[username]
    if !ok {
        return false
    }

    if v != password {
        return false
    }
    return true
}

func base64Encode(src string) string {
    encoded := base64.StdEncoding.EncodeToString([]byte(src))
    return encoded
}

func base64Decode(encoded string) string {
    decoded, _ := base64.StdEncoding.DecodeString(encoded)
    return string(decoded)
}

func randomStr() string {
    // 生成随机数
    rand.Seed(time.Now().UnixNano())
    random := rand.Intn(100000)

    // 格式化为05位字符串
    str := fmt.Sprintf("%05d", random)

    return str
}

func login(w http.ResponseWriter, r *http.Request) {
    username := r.FormValue("username")
    password := r.FormValue("password")

    if isValid(username, password) {
        session, err := store.Get(r, "server.com_"+username)
        if err != nil {
            fmt.Println("get session from session store error:", err)
            http.Error(w, "Internal error", http.StatusInternalServerError)
        }

        // 设置session数据
        random := randomStr()
        usernameB64 := base64Encode(username + "-" + random)
        session.Values["random"] = random
        session.Save(r, w)

        // 设置cookie
        cookie := http.Cookie{Name: "server.com-session", Value: usernameB64}
        http.SetCookie(w, &cookie)

        // 登录成功,跳转到calc页面
        http.Redirect(w, r, "/calc", http.StatusSeeOther)
    } else {
        http.Error(w, "Invalid username or password", http.StatusUnauthorized) // 401
    }
}

我们使用了gorilla/sessions这个Go社区广泛使用的session库来实现服务端session的相关操作。以admin用户登录为例,当用户名和密码认证成功后,我们在session store中创建一个新的session:server.com_admin。然后生成一个随机数,将随机数存储在该session的名为”random”的key的下面。之后,让客户端设置cookie,name为server.com-session。值为username和random按特定格式组合后的base64编码值。

登录成功后,浏览器会跳到calc页面,这里我们输入两个整数,并点击”calc”按钮提交,提交动作会发送请求到calcAdd Handler中:

// authn-examples/password/session/main.go

func calcAdd(w http.ResponseWriter, r *http.Request) {
    // 1. 获取Cookie中的Session
    cookie, err := r.Cookie("server.com-session")
    if err != nil {
        http.Error(w, "找不到cookie,请重新登录", 401)
        return
    }
    fmt.Printf("found cookie: %#v\n", cookie)

    // 2. 获取Session对象
    usernameB64 := cookie.Value
    usernameWithRandom := base64Decode(usernameB64)

    ss := strings.Split(usernameWithRandom, "-")
    username := ss[0]
    random := ss[1]
    session, err := store.Get(r, "server.com_"+username)
    if err != nil {
        http.Error(w, "找不到session, 请重新登录", 401)
        return
    }

    randomInSs := session.Values["random"]
    if random != randomInSs {
        http.Error(w, "session中信息不匹配, 请重新登录", 401)
        return
    }

    // 3. 转换为整型参数
    a, err := strconv.Atoi(r.FormValue("a"))
    if err != nil {
        http.Error(w, "参数错误", 400)
        return
    }

    b, err := strconv.Atoi(r.FormValue("b"))
    if err != nil {
        http.Error(w, "参数错误", 400)
        return
    }

    // 4. 计算并返回结果
    result := a + b
    w.Write([]byte(fmt.Sprintf("%d", result)))
}

calcAdd Handler会提取Cookie “server.com-session”中的值,根据值信息查找服务端本地是否存储了对应的session,并校验与session中存储的随机码是否一致。验证通过后,直接返回结算结果;否则提醒客户端重新登录。

前面说过,session是一种有状态的辅助身份认证机制,需要客户端和服务端的配合完成,一旦客户端禁用了Cookie机制,上述的示例实现就失效了。当然有读者会说,Session可以不基于Cookie来实现,可以用URL重写、隐藏表单字段、将Session ID放入URL路径等方式来实现,客户端也可以用LocalStorage等前端存储机制来替代Cookie。但无论哪种实现,这种有状态机制带来的复杂性都不低,并且在分布式环境中需要session共享和同步机制,影响了scaling。

随着微服务架构的广泛使用,无需在服务端存储额外信息、天然支持后端服务分布式多实例的无状态的连续身份认证机制受到了更多的青睐。

其实基于HTTP的无状态认证机制早已有之,最常见的莫过于Basic Auth了,接下来,我们就从Basic Auth开始,说几种无状态身份认证机制。

3.3 Basic Auth:最早的无状态认证方式

Basic Auth是HTTP最原始的身份验证方式,在HTTP1.0规范中就已存在,其原因是HTTP是无状态协议,每次请求都需要进行身份验证才能访问受保护资源。

Basic Auth的原理也十分简单,客户端与服务端的交互如下图:

Basic Auth通过在客户端的请求报文中添加HTTP Authorization Header的形式向服务器端发送认证凭据。HTTP Authorization Header的构建通常分两步。

  • 将“username:password”的组合字符串进行Base64编码,编码值记作b64Token。
  • 将Authorization: Basic b64Token作为HTTP header的一个字段发送给服务器端。

服务端收到请请求后提取出Authorization字段并做Base64解码,得到username和password,然后与存储的信息作比对进行客户端身份认证。

我们来看一个与上图对应的示例的代码,先看客户端:

// authn-examples/password/basic/client/main.go

func main() {
    client := &http.Client{}
    req, _ := http.NewRequest("POST", "http://server.com:8080/", nil)

    // 发送默认请求
    response, err := client.Do(req)
    if err != nil {
        fmt.Println(err)
        return
    }

    // 解析响应头
    authHeader := response.Header.Get("WWW-Authenticate")
    loginReq, _ := http.NewRequest("POST", "http://server.com:8080/login", nil)
    username := "admin"
    password := "123456"

    // 判断认证类型
    if !strings.Contains(authHeader, "Basic") {
        // 不支持的认证类型
        fmt.Println("Unsupported authentication type:", authHeader)
        return
    }

    // 使用Basic Auth, 添加Basic Auth头
    loginReq.SetBasicAuth(username, password)
    response, err = client.Do(loginReq)

    // 打印响应状态
    fmt.Println(response.StatusCode)

    // 打印响应包体
    defer response.Body.Close()
    body, err := io.ReadAll(response.Body)
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(string(body))
}

客户端的代码比较简单,并且流程与图中的交互流程是完全一样的。而服务端就是一个简单的http server,对来自客户端的带有basic auth的请求进行身份认证:

// authn-examples/password/basic/server/main.go

func main() {
    // 创建一个基本的HTTP服务器
    mux := http.NewServeMux()

    username := "admin"
    password := "123456"

    // 针对/的handler
    mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
        // 返回401 Unauthorized响应
        w.Header().Set("WWW-Authenticate", "Basic realm=\"server.com\"")
        w.WriteHeader(http.StatusUnauthorized)
    })

    // login handler
    mux.HandleFunc("/login", func(w http.ResponseWriter, req *http.Request) {
        // 从请求头中获取Basic Auth认证信息
        user, pass, ok := req.BasicAuth()
        if !ok {
            // 认证失败
            w.WriteHeader(http.StatusUnauthorized)
            return
        }

        // 验证用户名密码
        if user == username && pass == password {
            // 认证成功
            w.WriteHeader(http.StatusOK)
            w.Write([]byte("Welcome to the protected resource!"))
        } else {
            // 认证失败
            http.Error(w, "Invalid username or password", http.StatusUnauthorized)
        }
    })

    // 监听8080端口
    err := http.ListenAndServe(":8080", mux)
    if err != nil {
        log.Fatal(err)
    }
}

采用Basic Auth身份认证方案的客户端在每个请求中都要在Header中加上Basic Auth形式的身份信息,但服务端无需像Session那样存储任何额外的信息。

不过很显然,Basic Auth这种采用明文传输身份信息的方式在安全性方面饱受诟病,为了避免在Header传输明文的安全问题,RFC 2617(以及后续更新版RFC 7616)定义了HTTP Digest身份认证方式。Digest访问认证不再明文传输密码,而是传递用hash算法处理后密码摘要,相对Basic Auth验证安全性更高。接下来,我们就来看看HTTP Digest认证方式。

3.4 基于HTTP Digest认证

Digest是一种HTTP摘要认证,你可以把它看作是Basic Auth的改良版本,针对Base64明文发送的风险,Digest认证把用户名和密码加盐(一个被称为Nonce的随机值作为盐值)后,再通过MD5/SHA等哈希算法取摘要放到请求的Header中发送出去。Digest的认证过程如下图:

相对于Basic Auth,Digest Auth的一些值的生成过程还是略复杂的,这里给出一个示例性质的代码示例,可能不完全符合Digest规范,大家通过示例理解Digest的认证过程就可以了。

注:如要使用符合RFC 7616的Digest规范(或老版RFC 2617规范),可以找一些第三方包,比如https://github.com/abbot/go-http-auth(只满足RFC 2617)。

// authn-examples/password/digest/client/main.go

func main() {
    client := &http.Client{}
    req, _ := http.NewRequest("POST", "http://server.com:8080/", nil)

    // 发送默认请求
    response, err := client.Do(req)
    if err != nil {
        fmt.Println(err)
        return
    }

    // 解析响应头
    authHeader := response.Header.Get("WWW-Authenticate")
    loginReq, _ := http.NewRequest("POST", "http://server.com:8080/login", nil)
    username := "admin"
    password := "123456"

    // 判断认证类型
    if !strings.Contains(authHeader, "Digest") {
        // 不支持的认证类型
        fmt.Println("Unsupported authentication type:", authHeader)
        return
    }

    // 使用Digest Auth

    //随机数
    cnonce := GenNonce()

    //生成HA1
    ha1 := GetHA1(username, password, cnonce)

    //构建Authorization头
    auth := "Digest username=\"" + username + "\", nonce=\"" + cnonce + "\", algorithm=MD5, response=\"" + GetResponse(ha1, cnonce) + "\""

    loginReq.Header.Set("Authorization", auth)
    response, err = client.Do(loginReq)

    // 打印响应状态
    fmt.Println(response.StatusCode)

    // 打印响应包体
    defer response.Body.Close()
    body, err := io.ReadAll(response.Body)
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(string(body))
}

// 生成随机数
func GenNonce() string {
    h := md5.New()
    io.WriteString(h, fmt.Sprint(rand.Int()))
    return hex.EncodeToString(h.Sum(nil))
}

// 根据用户名密码和随机数生成HA1
func GetHA1(username, password, cnonce string) string {
    h := md5.New()
    io.WriteString(h, username+":"+cnonce+":"+password)
    return hex.EncodeToString(h.Sum(nil))
}

// 根据HA1,随机数生成response
func GetResponse(ha1, cnonce string) string {
    h := md5.New()
    io.WriteString(h, strings.ToUpper("md5")+":"+ha1+":"+cnonce+"::"+strings.ToUpper("md5"))
    return hex.EncodeToString(h.Sum(nil))
}

客户端使用username、password和随机数生成摘要以及一个response码,并通过请求的头Authorization字段发给服务端。

服务端解析Authorization字段中的各个值,然后采用同样的算法算出一个新response,与请求中的response比对,如果一致,则认为认证成功:

// authn-examples/password/digest/server/main.go

func main() {
    mux := http.NewServeMux()

    password := "123456"

    // 针对/的handler
    mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
        // 返回401 Unauthorized响应
        w.Header().Set("WWW-Authenticate", "Digest realm=\"server.com\"")
        w.WriteHeader(http.StatusUnauthorized)
    })

    // login handler
    mux.HandleFunc("/login", func(w http.ResponseWriter, req *http.Request) {
        fmt.Println(req.Header)

        //验证参数
        if Verify(req, password) {
            fmt.Fprintln(w, "Verify Success!")
        } else {
            w.WriteHeader(401)
            fmt.Fprintln(w, "Verify Failed!")
        }
    })

    // 监听8080端口
    err := http.ListenAndServe(":8080", mux)
    if err != nil {
        log.Fatal(err)
    }
}

func Verify(r *http.Request, password string) bool {
    auth := r.Header.Get("Authorization")
    params := strings.Split(auth, ",")
    var username, cnonce, response string

    for _, p := range params {
        p := strings.Trim(p, " ")
        kv := strings.Split(p, "=")
        if kv[0] == "Digest username" {
            username = strings.Trim(kv[1], "\"")
        }
        if kv[0] == "nonce" {
            cnonce = strings.Trim(kv[1], "\"")
        }
        if kv[0] == "response" {
            response = strings.Trim(kv[1], "\"")
        }
    }

    if username == "" {
        return false
    }

    //根据用户名密码及随机数生成HA1
    ha1 := GetHA1(username, password, cnonce)

    //自己生成response与请求中response对比
    return response == GetResponse(ha1, cnonce)
}

虽然实现了无状态,安全性也高于Basic Auth,但Digest方式的用户体验依然有限:每次向服务端发送请求,客户端都要进行一次复杂计算,服务端也要再做一次相同的验算和比对。

那么是否有一种体验更为良好的无状态身份认证方式呢?我们接下来看看基于Token的认证方式。

4. 无状态:基于Token的认证

基于Token的认证方式的备受青睐得益于Web领域前后端分离架构的发展以及微服务架构的流行,在API调用和网站间需要轻量级的认证机制来传递用户信息。Token认证机制正好满足这一需求,而JWT(JSON Web Token)是目前Token格式标准中使用最广的一种。

4.1 JWT原理

JWT由头部(Header)、载荷(Payload)和签名(Signature)三部分组成,三部分之间用圆点连接,其形式如下:

xxxxx.yyyyy.zzzzz

一个真实的JWT token的例子如下面来自jwt.io站点的截图):

JWT token的生成过程也非常清晰,下图展示了上述截图中jwt token的生成过程:

如果你不想依赖第三方库,也可以自己实现生成token的函数,下面是一个示例:

// authn-examples/jwt/scratch/main.go

package main

import (
    "crypto/hmac"
    "crypto/sha256"
    "encoding/base64"
    "encoding/json"
    "fmt"
)

type Header struct {
    Alg string `json:"alg"`
    Typ string `json:"typ"`
}

type Claims struct {
    Sub  string `json:"sub"`
    Name string `json:"name"`
    Iat  int64  `json:"iat"`
}

// GenerateToken:不依赖第三方库的JWT生成实现
func GenerateToken(claims *Claims, key string) (string, error) {
    header, _ := json.Marshal(Header{
        Alg: "HS256",
        Typ: "JWT",
    })
    // 序列化Payload
    payload, err := json.Marshal(claims)
    if err != nil {
        return "", err
    }

    // 拼接成JWT字符串
    headerEncoded := base64.RawURLEncoding.EncodeToString(header)
    payloadEncoded := base64.RawURLEncoding.EncodeToString([]byte(payload))

    encodedToSign := headerEncoded + "." + payloadEncoded

    // 使用HMAC+SHA256签名
    hash := hmac.New(sha256.New, []byte(key))
    hash.Write([]byte(encodedToSign))
    sig := hash.Sum(nil)
    sigEncoded := base64.RawURLEncoding.EncodeToString(sig)

    var token string
    token += headerEncoded
    token += "."
    token += payloadEncoded
    token += "."
    token += sigEncoded

    return token, nil
}

func main() {
    var claims = &Claims{
        Sub:  "1234567890",
        Name: "John Doe",
        Iat:  1516239022,
    }

    result, _ := GenerateToken(claims, "iamtonybai")
    fmt.Println(result)
}

对照着上面图示的流程,理解这个示例非常容易。当然jwt.io官方也维护了一个使用简单且灵活性更好的Go module:golang-jwt/jwt,用这个go module生成上述token的示例代码如下:

// authn-examples/jwt/golang-jwt/main.go

import (
    "fmt"
    "time"

    jwt "github.com/golang-jwt/jwt/v5"
)

type MyCustomClaims struct {
    Sub                  string `json:"sub"`
    Name                 string `json:"name"`
    jwt.RegisteredClaims        // use its Subject and IssuedAt
}

func main() {
    mySigningKey := []byte("iamtonybai")

    // Create claims with multiple fields populated
    claims := MyCustomClaims{
        Name: "John Doe",
        Sub:  "1234567890",
        RegisteredClaims: jwt.RegisteredClaims{
            IssuedAt: jwt.NewNumericDate(time.Unix(1516239022, 0)), //  1516239022
        },
    }

    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    ss, _ := token.SignedString(mySigningKey)
    fmt.Println(ss)

    _, err := verifyToken(ss, "iamtonybai")
    if err != nil {
        fmt.Println("invalid token:", err)
        return
    }

    fmt.Println("valid token")
}

这段代码中还包含了一个对jwt token验证合法性的函数verifyToken,服务端每次收到客户端请求中携带的token时,都可以使用verifyToken来验证token是否合法,下面是verifyToken的实现逻辑:

// authn-examples/jwt/golang-jwt/main.go

// verifyToken 验证JWT函数
func verifyToken(tokenString, key string) (*jwt.Token, error) {
    // 解析Token
    token, err := jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
        return []byte(key), nil
    })

    if err != nil {
        return nil, err
    }

    // 验证签名
    if _, ok := token.Method.(*jwt.SigningMethodHMAC); !ok {
        return nil, jwt.ErrSignatureInvalid
    }

    return token, nil
}

服务端验证token的逻辑是先解析token,得到header、payload对应的base64UrlEncoded后的结果,然后用key重新生成签名,对比生成的签名与token携带的签名是否一致。

那么在Web应用中如何实现基于jwt token的身份认证呢?我们继续往下看。

4.2 使用JWT token做身份认证

在前面讲解Basic Auth、Digest Auth时,Basic Auth、Digest等服务端认证方式利用了HTTP Header的Authorization字段,基于JWT token的认证也是基于Authorization字段,只不过前缀从Basic、Digest换成了Bearer

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpYXQiOjE2OTc4NjE5MzIsInVzZXJuYW1lIjoiYWRtaW4ifQ.go6NhfmYPZbtHEuJ1oULG890neo0yVdtFJwfAvHhxyE

基于JWT token的身份认证方式的客户端与服务端的交互流程如下图:

在这幅示意图中,客户端先用basic auth方式登录服务端,服务端验证通过后,在登录应答中写入一个jwt token作为后续客户端访问服务端其他功能的依据。客户端从登录应答的包体中解析出jwt token后,可以将该token存放在LocalStorage中,然后在后续的发向该服务端的所有请求中都带上这个jwt token。服务端对这些请求都会校验其携带的jwt token,只有验证通过的请求才能被正确处理。

下面来看看对应示意图的示例源码,先来看一下客户端:

// authn-examples/jwt-authn/client/main.go

func main() {
    client := &http.Client{}
    req, _ := http.NewRequest("POST", "http://server.com:8080/", nil)

    // 发送默认请求
    response, err := client.Do(req)
    if err != nil {
        fmt.Println(err)
        return
    }

    // 解析响应头
    authHeader := response.Header.Get("WWW-Authenticate")
    loginReq, _ := http.NewRequest("POST", "http://server.com:8080/login", nil)
    username := "admin"
    password := "123456"

    // 判断认证类型
    if !strings.Contains(authHeader, "Basic") {
        // 不支持的认证类型
        fmt.Println("Unsupported authentication type:", authHeader)
        return
    }

    // 使用Basic Auth, 添加Basic Auth头
    loginReq.SetBasicAuth(username, password)
    response, err = client.Do(loginReq)

    fmt.Println(response.StatusCode)

    // 从响应包体中获取服务端分配的jwt token
    defer response.Body.Close()
    body, err := io.ReadAll(response.Body)
    if err != nil {
        fmt.Println(err)
        return
    }

    token := string(body)
    fmt.Println("token=", token)

    // 基于token访问服务端其他功能
    apiReq, _ := http.NewRequest("POST", "http://server.com:8080/calc", nil)
    apiReq.Header.Set("Authorization", "Bearer "+token)
    response, err = client.Do(apiReq)
    fmt.Println(response.StatusCode)
    defer response.Body.Close()
    body, err = io.ReadAll(response.Body)
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(string(body))
}

客户端的操作流程与示意图一样,先用basic auth登录server,通过验证后,拿到服务端生成的token。后续到该服务端的所有请求只需在Header中带上token即可。

服务端的代码如下:

// authn-examples/jwt-authn/server/main.go

func main() {
    // 创建一个基本的HTTP服务器
    mux := http.NewServeMux()

    username := "admin"
    password := "123456"
    key := "iamtonybai"

    // 针对/的handler
    mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
        // 返回401 Unauthorized响应
        w.Header().Set("WWW-Authenticate", "Basic realm=\"server.com\"")
        w.WriteHeader(http.StatusUnauthorized)
    })

    // login handler
    mux.HandleFunc("/login", func(w http.ResponseWriter, req *http.Request) {
        // 从请求头中获取Basic Auth认证信息
        user, pass, ok := req.BasicAuth()
        if !ok {
            // 认证失败
            w.WriteHeader(http.StatusUnauthorized)
            return
        }

        // 验证用户名密码
        if user == username && pass == password {
            // 认证成功,生成token
            token := jwt.NewWithClaims(jwt.SigningMethodHS256, jwt.MapClaims{
                "username": username,
                "iat":      jwt.NewNumericDate(time.Now().Add(time.Hour * 24)),
            })
            signedToken, _ := token.SignedString([]byte(key))
            w.Write([]byte(signedToken))
        } else {
            // 认证失败
            http.Error(w, "Invalid username or password", http.StatusUnauthorized)
        }
    })

    // calc handler
    mux.HandleFunc("/calc", func(w http.ResponseWriter, req *http.Request) {
        // 读取并校验jwt token
        token := req.Header.Get("Authorization")[len("Bearer "):]
        fmt.Println(token)
        if _, err := verifyToken(token, key); err != nil {
            // 认证失败
            http.Error(w, "Invalid token", http.StatusUnauthorized)
            return
        }
        w.Write([]byte("invoke calc ok"))
    })

    // 监听8080端口
    err := http.ListenAndServe(":8080", mux)
    if err != nil {
        log.Fatal(err)
    }
}

我们看到,除了在login handler中使用basic auth做用户密码验证外,其他功能handler(如calc)中都使用token进行身份验证。

与传统会话式(session)认证相比,JWT是无状态的,更适用于分布式微服务架构。与Basic auth和digest相比,jwt在使用体验上又领先一筹。凭借其无需在服务端保存会话状态、天生适合分布式架构、令牌内容可以自定义扩展等优势,现阶段,jwt已广泛应用于以下场合:

  • 前后端分离的Web应用和API认证
  • 跨域单点登录(SSO)
  • 微服务架构下服务间认证
  • 无状态和移动应用认证

不过JWT认证方式也有不足,比如:客户端要承担令牌存储成本、如果令牌泄露未及时失效可能被滥用等。

讲到这里,从基本的用户名密码认证,到加上密码散列的Digest认证,再到应用会话管理的Session认证,以及基于令牌的JWT认证,我们见证了认证机制的不断进步和发展。

这些方法主要依赖账号密码这单一要素,提供了不同程度的安全性。但是随着互联网的快速发展,开发人员也在考虑改善用户名密码这种方式的使用体验,一些一次性密码认证方式便走入了我们的生活。接下来我们就来简单说一下一次性密码验证。

5. 基于一次性密码验证

一次性密码(One Time Password, OTP)是一种只能使用一次的密码,它在使用后立即失效。OTP生成密码的算法基于时间,在很短的时间内(一般分钟内或更短时间内)只能使用一次;每次验证都需要生成和输入新的密码,不能重复使用。

一次性密码的优势主要有以下几点:

  • 安全性高:一次性密码只能使用一次,因此即使攻击者获得了密码,也无法重复使用。
  • 易用性强:一次性密码通常是数字或字母组成的短语,易于记忆和输入。
  • 成本低:一次性密码的生成和验证成本相对较低。

信息论已经从理论上证明了:一次性密码本是无条件安全的,在理论上是无法破译的。不过现实中,还没有一种理想的一次性密码,大多数一次性密码还处于身份认证的辅助地位,多作为第二要素。

短信验证码就是一种我们生活中常见的一次性密码,它是利用移动运营商的短信通道传输的一次性密码。短信验证码通常由6位数字组成,有效期为几分钟,并且只能使用一次,通过短信发送给用户,非常方便用户使用,用户无需有记住密码的烦恼。

短信验证码的工作流程如下:

  • 客户端发起认证请求,如登录或注册;
  • 服务器生成6位随机数字作为验证码,通过文本短信发送到用户注册的手机号;
  • 用户接收短信并输入验证码进行验证;
  • 服务器通过时间戳验证此验证码是否有效(一般在5分钟内)。
  • 验证码只能使用一次,服务器会将此条记录标记为使用。

短信验证码的优势是方便快捷。目前国内大多数主流Web应用都支持手机验证码登录。短信验证码通常用于以下场景:

  • 用户注册
  • 用户登录
  • 支付或交易
  • 辅助密码找回等

不过手机验证码这种一次性密码的安全性相对较低,因为短信可以被截获,攻击者可以通过截获短信来获取验证码。

除短信验证码外,还有其他常见的OTP实现形式:

  • 手机应用软件OTP:使用专门的手机APP软件生成OTP码,如Google Authenticator、Microsoft Authenticator等。
  • 电子邮件OTP:类似短信验证码,但通过邮件发送6-8位数字验证码到用户注册的邮箱。
  • 语音验证码OTP:服务端调用第三方语音平台,使用文本到语音功能给用户自动拨打认证电话,提示验证码。

总体来说,OTP越来越多地被用到用户身份认证上来,随着以后技术的进步,其应用的广度和深度会进一步扩大,安全性也会得到进一步提升。基于传统密码的认证方式早晚会被扔到历史的旧物箱中。一些大厂,如Google都在研究替代传统密码的技术,比如Passkey等,一些Web标准组织也在做无密码认证的规范,比如WebAuthn等。

6. 小结

就写到这里吧,篇幅有些长了,关于OAuth、OpenID等身份认证技术就不在这里写了,后续找机会单独梳理。

本文我们介绍了多种Web应用的身份认证技术方案,各种认证技术会依据对安全性、使用性和扩展性的不同需求而存在和发展。了解每种技术的原理和优劣势,可帮助我们更好地选择适合的方案。

首次梳理这么多Web应用身份认证的资料,可能有些描述并不完全正确,欢迎指正。在撰写本文时,大语言模型帮助编写部分文字素材和代码。

本文示例所涉及的Go源码可以在这里下载。

7. 参考资料


“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群!高品质首发Go技术文章,“三天”首发阅读权,每年两期Go语言发展现状分析,每天提前1小时阅读到新鲜的Gopher日报,网课、技术专栏、图书内容前瞻,六小时内必答保证等满足你关于Go语言生态的所有需求!2023年,Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码,关注代码质量并深入理解Go核心技术,并继续加强与星友的互动。欢迎大家加入!

img{512x368}
img{512x368}

img{512x368}
img{512x368}

著名云主机服务厂商DigitalOcean发布最新的主机计划,入门级Droplet配置升级为:1 core CPU、1G内存、25G高速SSD,价格5$/月。有使用DigitalOcean需求的朋友,可以打开这个链接地址:https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻) – https://gopherdaily.tonybai.com

我的联系方式:

  • 微博(暂不可用):https://weibo.com/bigwhite20xx
  • 微博2:https://weibo.com/u/6484441286
  • 博客:tonybai.com
  • github: https://github.com/bigwhite
  • Gopher Daily归档 – https://github.com/bigwhite/gopherdaily

商务合作方式:撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats