[GH-ISSUE #3280] [Feature Request] tls supports write cert in the config file directly

gitea-mirror commented

2026-05-05 13:41:56 -06:00

Owner

Originally created by @graydovee on GitHub (Jan 31, 2023).
Original GitHub issue: https://github.com/fatedier/frp/issues/3280

Describe the feature request

我在家搭了一个kubernets集群，所以没有公网ip。但想能公网访问我的服务，所以想基于frp开发一个ingress controller 。目前的原理是watch ingress资源，并通过frpc的web接口更新配置文件。
现在在支持tls的时候遇到了一个问题，kubernetes ingress的tls信息是以secrets的方式声明的，无法动态挂载文件到frpc容器中，所以希望证书能直接以base64编码的方式填写在frpc.ini中

[common]
server_addr = x.x.x.x
server_port = 7000

[test_htts2http]
type = https
custom_domains = test.yourdomain.com

plugin = https2http
plugin_local_addr = 127.0.0.1:80

# HTTPS 证书相关的配置
plugin_crt_base64= 公钥的base64
plugin_key_base64 = 私钥的base64
plugin_host_header_rewrite = 127.0.0.1
plugin_header_X-From-Where = frp

Describe alternatives you've considered

No response

Affected area

Docs
Installation
Performance and Scalability
Security
User Experience
Test and Release
Developer Infrastructure
Client Plugin
Server Plugin
Extensions
Others

Originally created by @graydovee on GitHub (Jan 31, 2023). Original GitHub issue: https://github.com/fatedier/frp/issues/3280 ### Describe the feature request 我在家搭了一个kubernets集群，所以没有公网ip。但想能公网访问我的服务，所以想基于frp开发一个[ingress controller](https://github.com/graydovee/ingress-frp) 。目前的原理是watch ingress资源，并通过frpc的web接口更新配置文件。现在在支持tls的时候遇到了一个问题，kubernetes ingress的tls信息是以secrets的方式声明的，无法动态挂载文件到frpc容器中，所以希望证书能直接以base64编码的方式填写在frpc.ini中 ```ini [common] server_addr = x.x.x.x server_port = 7000 [test_htts2http] type = https custom_domains = test.yourdomain.com plugin = https2http plugin_local_addr = 127.0.0.1:80 # HTTPS 证书相关的配置 plugin_crt_base64= 公钥的base64 plugin_key_base64 = 私钥的base64 plugin_host_header_rewrite = 127.0.0.1 plugin_header_X-From-Where = frp ``` ### Describe alternatives you've considered _No response_ ### Affected area - [ ] Docs - [ ] Installation - [ ] Performance and Scalability - [ ] Security - [X] User Experience - [ ] Test and Release - [ ] Developer Infrastructure - [ ] Client Plugin - [ ] Server Plugin - [ ] Extensions - [ ] Others

gitea-mirror closed this issue

2026-05-05 13:41:56 -06:00

gitea-mirror commented

2026-05-05 13:41:58 -06:00

Author

Owner

@graydovee commented on GitHub (Jan 31, 2023):

我现在改了一版测下来基本可用，没问题的话我可以提个pr

@graydovee commented on GitHub (Jan 31, 2023): 我现在改了一版测下来基本可用，没问题的话我可以提个pr

gitea-mirror commented

2026-05-05 13:41:59 -06:00

Author

Owner

@fatedier commented on GitHub (Jan 31, 2023):

https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod

@fatedier commented on GitHub (Jan 31, 2023): https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod

gitea-mirror commented

2026-05-05 13:42:00 -06:00

Author

Owner

@graydovee commented on GitHub (Jan 31, 2023):

@fatedier
我目前的想法是fpc作为daemonset，起固定数量作为集群出口, 但pod在创建之后无法新增secrets挂载，新申明的ingress除非frpc pod重建，否则无法在frpc上挂载新的secrets。

当然还有个方案是为每个ingress单独创建frpc的pod, 不但会浪费pod, 而且由于挂载不能跨namespace, 这么做的话会在用户的namespace起pod，这有时候会和用户namespace的node权限冲突。

我也想过加个sidercar用于同步secrets信息，但这总感觉太重了

想下来感觉还是frpc支持最简洁

@graydovee commented on GitHub (Jan 31, 2023): @fatedier 我目前的想法是fpc作为daemonset，起固定数量作为集群出口, 但pod在创建之后无法新增secrets挂载，新申明的ingress除非frpc pod重建，否则无法在frpc上挂载新的secrets。当然还有个方案是为每个ingress单独创建frpc的pod, 不但会浪费pod, 而且由于挂载不能跨namespace, 这么做的话会在用户的namespace起pod，这有时候会和用户namespace的node权限冲突。我也想过加个sidercar用于同步secrets信息，但这总感觉太重了想下来感觉还是frpc支持最简洁

gitea-mirror commented

2026-05-05 13:42:00 -06:00

Author

Owner

@fatedier commented on GitHub (Feb 1, 2023):

通用的问题应该尽量在通用的层面解决，不倾向于定制化这样的内容。今天这个服务会遇到这个问题，那么以后其他服务也可能会遇到类似的问题。

@fatedier commented on GitHub (Feb 1, 2023): 通用的问题应该尽量在通用的层面解决，不倾向于定制化这样的内容。今天这个服务会遇到这个问题，那么以后其他服务也可能会遇到类似的问题。

gitea-mirror commented

2026-05-05 13:42:01 -06:00

Author

Owner

@graydovee commented on GitHub (Feb 1, 2023):