尧图网站建设 
oauth2-proxy TLS 配置实战在代理层或 Nginx 反向代理层终结 TLS【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxy在 oauth2-proxy 中部署 HTTPS 有两种推荐方式由 oauth2-proxy 自身终结 TLS或由前置的反向代理如 Nginx、Amazon ELB、GCP Load Balancing终结 TLS。本文围绕仓库官方文档docs/versioned_docs/version-7.10.x/configuration/tls.md展开完整继承两种方案的配置步骤并结合 pkg/proxyhttp/server.go 与 pkg/apis/options/legacy_options.go 的源码实现讲清各参数在底层如何生效、默认值是什么以及两种方案各自的适用场景。方案一在 OAuth2 Proxy 终结 TLS基本配置通过提供证书与私钥文件让 oauth2-proxy 直接以 HTTPS 服务./oauth2-proxy \ --email-domainyourcompany.com \ --upstreamhttp://127.0.0.1:8080/ \ --tls-cert-file/path/to/cert.pem \ --tls-key-file/path/to/cert.key \ --cookie-secret... \ --cookie-securetrue \ --provider... \ --client-id... \ --client-secret...在 legacy_options.go 中这两个参数定义为--tls-cert-file配置文件键tls_cert_file证书文件路径--tls-key-file配置文件键tls_key_file私钥文件路径。一个值得注意的兼容行为从 legacy_options.go 的 convert() 方法 可以看到一旦指定了--tls-cert-file或--tls-key-fileoauth2-proxy 会把BindAddress明文 HTTP 监听地址置空即只启动一个 HTTPS 服务不再额外监听 HTTP 端口这是为保持向后兼容而做的单服务处理。证书数据最终由 pkg/proxyhttp/server.go 的 getCertificate() 通过tls.X509KeyPair解析为 X.509 证书对证书与密钥的读取来源是SecretSource因此不仅支持文件路径Alpha 配置中还可以用 inline 方式直接提供 PEM 数据见 pkg/apis/options/server.go 的 TLS 结构体。TLS 版本与密码套件该方案下 TLS 的可定制能力有限只有两个可调项最小 TLS 版本通过--tls-min-versionTLS1.3设置。从 server.go 的 setupTLSListener() 可以确认默认MinVersion为tls.VersionTLS12即 TLS 1.2MaxVersion恒为tls.VersionTLS13。无论最小版本如何配置TLS 1.3 始终是当前支持的最大版本该参数只接受TLS1.2或TLS1.3两个取值传入其他值会直接报错unknown TLS MinVersion config provided进程无法启动。服务端密码套件通过--tls-cipher-suiteTLS_RSA_WITH_RC4_128_SHA指定可多次给出StringSlice类型。若不指定则使用构建 oauth2-proxy 所用 Go 版本crypto/tls标准库的默认安全套件列表。密码套件名称的合法性由 parseCipherSuites() 校验它会同时遍历tls.CipherSuites()与tls.InsecureCipherSuites()建立名称到 ID 的映射任何未知名称都会导致启动失败unknown TLS cipher suite name specified。pkg/proxyhttp/server_test.go 中的测试表项覆盖了合法套件与未知套件两种场景验证了该校验路径。除版本与套件外setupTLSListener() 还硬编码了NextProtos: [http/1.1]并让 listener 套上 tcpKeepAliveListenerTCP keep-alive 周期 3 分钟以让死连接如下载中断开的笔记本最终自动清理。这些行为无法通过命令行调整这是官方文档所说“该方案下 TLS 定制能力有限”的具体含义。Alpha 配置中的等价写法新版 Alpha 配置--alpha-config中上述能力对应 pkg/apis/options/server.go 的server块server: secureBindAddress: https://0.0.0.0:8443 tls: key: fromFile: /path/to/cert.key cert: fromFile: /path/to/cert.pem minVersion: TLS1.3 # 仅 TLS1.2 / TLS1.3 cipherSuites: # 可选Go crypto/tls 套件名称 - TLS_RSA_WITH_AES_256_GCM_SHA384Legacy 命令行参数经 convert() 转换后会填入同一个TLS结构体两者等价。方案二在反向代理如 Nginx终结 TLS这是生产环境更常见的部署形态Nginx或云厂商负载均衡器在 443 端口处理 SSLoauth2-proxy 只在内网以 HTTP 4180 端口运行。外部访问入口形如https://internal.yourcompany.com/。监听地址调整oauth2-proxy 默认监听127.0.0.1:4180见 legacy_options.go 默认值。若前置的是 Amazon ELB 或 GCP 负载均衡器等外部设备需要让它监听所有接口--http-address0.0.0.0:4180 # 或等价写法 --http-addresshttp://:4180从 getNetworkScheme() 可见http://前缀会被解析为普通 TCP 监听两种写法效果一致。Nginx 示例配置官方文档给出的示例如下注意其中使用Strict-Transport-Security响应头通过 HSTS 将后续请求强制固定到 HTTPSserver { listen 443 default ssl; server_name internal.yourcompany.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/cert.key; add_header Strict-Transport-Security max-age2592000; location / { proxy_pass http://127.0.0.1:4180; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 1; proxy_send_timeout 30; proxy_read_timeout 30; } }配套的 oauth2-proxy 命令行./oauth2-proxy \ --email-domainyourcompany.com \ --upstreamhttp://127.0.0.1:8080/ \ --cookie-secret... \ --cookie-securetrue \ --provider... \ --reverse-proxytrue \ --client-id... \ --client-secret...这里的关键参数是--reverse-proxytrue它控制 oauth2-proxy 是否接受来自反向代理的X-Real-IP等头部见 pkg/apis/options/options.go 的参数说明。在 Nginx 一侧proxy_set_header Host $host与X-Real-IP $remote_addr正是与它配套的两个头。源码层面还提供了一个安全性相关的补充--trusted-proxy-ip选项可以限定“哪些来源 IP 的X-Forwarded-*头部会被信任”防止头部伪造。在反向代理终结 TLS 的拓扑中把它配置为反向代理的地址是更稳妥的做法默认为了向后兼容信任所有 IP。两种方案如何取舍在 oauth2-proxy 终结 TLS链路简单、无中间层适合裸机或单机部署代价是 TLS 参数只能调最小版本与密码套件且证书更新需要重新加载 oauth2-proxy 进程证书在启动时一次性加载见 setupTLSListener()。在反向代理终结 TLSTLS 参数协议版本、套件、证书轮换全部交给 Nginx/负载均衡器管理oauth2-proxy 专注认证逻辑更适合集群与云上部署代价是必须正确配置--reverse-proxy及配套的信任源否则客户端真实 IP 会取错。此外仓库中 contrib/local-environment/nginx.conf 与 docker-compose-nginx.yaml 提供了一整套 Nginx oauth2-proxy 的本地演示环境可作为方案二的可运行参照。小结oauth2-proxy 的 TLS 支持覆盖两种终结位置自行终结时通过--tls-cert-file/--tls-key-file/--tls-min-version/--tls-cipher-suite四个参数控制底层在 pkg/proxyhttp/server.go 中完成套件解析、版本约束TLS1.2–TLS1.3与证书加载交由 Nginx 等反向代理终结时则依靠--reverse-proxytrue、监听地址调整--http-address与Host/X-Real-IP头部传递来保证认证链路与客户端 IP 识别的正确性。相关测试见 pkg/proxyhttp/server_test.golegacy 参数转换逻辑见 pkg/apis/options/legacy_options.go。【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 oauth2-proxy TLS 配置实战：在代理层或 Nginx 反向代理层终结 TLS
oauth2-proxy TLS 配置实战在代理层或 Nginx 反向代理层终结 TLS【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxy在 oauth2-proxy 中部署 HTTPS 有两种推荐方式由 oauth2-proxy 自身终结 TLS或由前置的反向代理如 Nginx、Amazon ELB、GCP Load Balancing终结 TLS。本文围绕仓库官方文档docs/versioned_docs/version-7.10.x/configuration/tls.md展开完整继承两种方案的配置步骤并结合 pkg/proxyhttp/server.go 与 pkg/apis/options/legacy_options.go 的源码实现讲清各参数在底层如何生效、默认值是什么以及两种方案各自的适用场景。方案一在 OAuth2 Proxy 终结 TLS基本配置通过提供证书与私钥文件让 oauth2-proxy 直接以 HTTPS 服务./oauth2-proxy \ --email-domainyourcompany.com \ --upstreamhttp://127.0.0.1:8080/ \ --tls-cert-file/path/to/cert.pem \ --tls-key-file/path/to/cert.key \ --cookie-secret... \ --cookie-securetrue \ --provider... \ --client-id... \ --client-secret...在 legacy_options.go 中这两个参数定义为--tls-cert-file配置文件键tls_cert_file证书文件路径--tls-key-file配置文件键tls_key_file私钥文件路径。一个值得注意的兼容行为从 legacy_options.go 的 convert() 方法 可以看到一旦指定了--tls-cert-file或--tls-key-fileoauth2-proxy 会把BindAddress明文 HTTP 监听地址置空即只启动一个 HTTPS 服务不再额外监听 HTTP 端口这是为保持向后兼容而做的单服务处理。证书数据最终由 pkg/proxyhttp/server.go 的 getCertificate() 通过tls.X509KeyPair解析为 X.509 证书对证书与密钥的读取来源是SecretSource因此不仅支持文件路径Alpha 配置中还可以用 inline 方式直接提供 PEM 数据见 pkg/apis/options/server.go 的 TLS 结构体。TLS 版本与密码套件该方案下 TLS 的可定制能力有限只有两个可调项最小 TLS 版本通过--tls-min-versionTLS1.3设置。从 server.go 的 setupTLSListener() 可以确认默认MinVersion为tls.VersionTLS12即 TLS 1.2MaxVersion恒为tls.VersionTLS13。无论最小版本如何配置TLS 1.3 始终是当前支持的最大版本该参数只接受TLS1.2或TLS1.3两个取值传入其他值会直接报错unknown TLS MinVersion config provided进程无法启动。服务端密码套件通过--tls-cipher-suiteTLS_RSA_WITH_RC4_128_SHA指定可多次给出StringSlice类型。若不指定则使用构建 oauth2-proxy 所用 Go 版本crypto/tls标准库的默认安全套件列表。密码套件名称的合法性由 parseCipherSuites() 校验它会同时遍历tls.CipherSuites()与tls.InsecureCipherSuites()建立名称到 ID 的映射任何未知名称都会导致启动失败unknown TLS cipher suite name specified。pkg/proxyhttp/server_test.go 中的测试表项覆盖了合法套件与未知套件两种场景验证了该校验路径。除版本与套件外setupTLSListener() 还硬编码了NextProtos: [http/1.1]并让 listener 套上 tcpKeepAliveListenerTCP keep-alive 周期 3 分钟以让死连接如下载中断开的笔记本最终自动清理。这些行为无法通过命令行调整这是官方文档所说“该方案下 TLS 定制能力有限”的具体含义。Alpha 配置中的等价写法新版 Alpha 配置--alpha-config中上述能力对应 pkg/apis/options/server.go 的server块server: secureBindAddress: https://0.0.0.0:8443 tls: key: fromFile: /path/to/cert.key cert: fromFile: /path/to/cert.pem minVersion: TLS1.3 # 仅 TLS1.2 / TLS1.3 cipherSuites: # 可选Go crypto/tls 套件名称 - TLS_RSA_WITH_AES_256_GCM_SHA384Legacy 命令行参数经 convert() 转换后会填入同一个TLS结构体两者等价。方案二在反向代理如 Nginx终结 TLS这是生产环境更常见的部署形态Nginx或云厂商负载均衡器在 443 端口处理 SSLoauth2-proxy 只在内网以 HTTP 4180 端口运行。外部访问入口形如https://internal.yourcompany.com/。监听地址调整oauth2-proxy 默认监听127.0.0.1:4180见 legacy_options.go 默认值。若前置的是 Amazon ELB 或 GCP 负载均衡器等外部设备需要让它监听所有接口--http-address0.0.0.0:4180 # 或等价写法 --http-addresshttp://:4180从 getNetworkScheme() 可见http://前缀会被解析为普通 TCP 监听两种写法效果一致。Nginx 示例配置官方文档给出的示例如下注意其中使用Strict-Transport-Security响应头通过 HSTS 将后续请求强制固定到 HTTPSserver { listen 443 default ssl; server_name internal.yourcompany.com; ssl_certificate /path/to/cert.pem; ssl_certificate_key /path/to/cert.key; add_header Strict-Transport-Security max-age2592000; location / { proxy_pass http://127.0.0.1:4180; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 1; proxy_send_timeout 30; proxy_read_timeout 30; } }配套的 oauth2-proxy 命令行./oauth2-proxy \ --email-domainyourcompany.com \ --upstreamhttp://127.0.0.1:8080/ \ --cookie-secret... \ --cookie-securetrue \ --provider... \ --reverse-proxytrue \ --client-id... \ --client-secret...这里的关键参数是--reverse-proxytrue它控制 oauth2-proxy 是否接受来自反向代理的X-Real-IP等头部见 pkg/apis/options/options.go 的参数说明。在 Nginx 一侧proxy_set_header Host $host与X-Real-IP $remote_addr正是与它配套的两个头。源码层面还提供了一个安全性相关的补充--trusted-proxy-ip选项可以限定“哪些来源 IP 的X-Forwarded-*头部会被信任”防止头部伪造。在反向代理终结 TLS 的拓扑中把它配置为反向代理的地址是更稳妥的做法默认为了向后兼容信任所有 IP。两种方案如何取舍在 oauth2-proxy 终结 TLS链路简单、无中间层适合裸机或单机部署代价是 TLS 参数只能调最小版本与密码套件且证书更新需要重新加载 oauth2-proxy 进程证书在启动时一次性加载见 setupTLSListener()。在反向代理终结 TLSTLS 参数协议版本、套件、证书轮换全部交给 Nginx/负载均衡器管理oauth2-proxy 专注认证逻辑更适合集群与云上部署代价是必须正确配置--reverse-proxy及配套的信任源否则客户端真实 IP 会取错。此外仓库中 contrib/local-environment/nginx.conf 与 docker-compose-nginx.yaml 提供了一整套 Nginx oauth2-proxy 的本地演示环境可作为方案二的可运行参照。小结oauth2-proxy 的 TLS 支持覆盖两种终结位置自行终结时通过--tls-cert-file/--tls-key-file/--tls-min-version/--tls-cipher-suite四个参数控制底层在 pkg/proxyhttp/server.go 中完成套件解析、版本约束TLS1.2–TLS1.3与证书加载交由 Nginx 等反向代理终结时则依靠--reverse-proxytrue、监听地址调整--http-address与Host/X-Real-IP头部传递来保证认证链路与客户端 IP 识别的正确性。相关测试见 pkg/proxyhttp/server_test.golegacy 参数转换逻辑见 pkg/apis/options/legacy_options.go。【免费下载链接】oauth2-proxyA reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.项目地址: https://gitcode.com/GitHub_Trending/oa/oauth2-proxy创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考