Min tls 12 #3
Closed
Min tls 12 #3
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* chore(CI/CD): Bump Go version to 1.20 * chore(CI/CD): Bump actions/setup-go to v4 * chore(CI/CD): Fix go version
min_port and max_port was used falsely instead of min_relay_port and max_relay_port https://github.com/l7mp/stunner/blob/234767fa08e3b5e5db4a663575e6dab9b58c68e1/pkg/apis/v1alpha1/listener.go#L29
This change makes it possible for the STUNner dataplane component `stunnerd` to autodiscover its own configuration. This is achieved by implementing a CDS client for `stunnerd`: on startup the CDS client opens a WebSocket connection to a preconfigured CDS server and grabs an initial configuration. As long as the connection is open, the CDS server will push new configurations down to the client as they become available. This makes it possible to remove the unstability and latency associated with obtaining the fresh config by watching a config file mapped into the filesystem of `stunnerd` (the config file watcher remains available for the "legacy" dataplane mode). Major changes: - implement a generic config watcher interface and make the config file watcher and the CDS config poller two implementations of the interface - obtain the CDS client id from the environment as <STUNNER_NAMESPACE>/<STUNNER_NAME>, or fall back to the default (hostname) if the environment is not set - the initial zeroconfig is now emitted by the config file watcher (the CDS client does not use a zeroconfig to init `stunnerd` but rather waits for a valid config from the CDS server) - the ZeroConfig() and ParseConfig() functions are moved to the CDS client - stunnerd id is now avaiable in the config (`Admin.Name`) - tests are implemented at the CDS server side (the operator) that imports the CDS client
Scheduled to run on every second Tuesday
Rename listener protocols to harmonize with Gateway API protocol names. In particular, introduce: - TURN-UDP to mean "TURN over UDP", - TURN-TCP to mean "TURN over TCP", - TURN-TLS to mean "TURN over TLS", - TURN-DTLS to mean "TURN over DTLS", and - remove old shorthand names (UDP, TCP, TLS, DTLS). For more info on this change, see l7mp/stunner-gateway-operator#28
So far stunnerd has bound TURN server sockets to the corresponding listener address and used the same listener address to create the relayed transport address. This works well as long as it is deployed in a Kubernetes pod that has only a single IP address, but breaks on baremetal servers with multiple IPs. This change causes stunnerd to bind listener sockets to 0.0.0.0:<listener-port> and only use the listener address to create the relayed transport address.
Changes: - use full image name for neko - update stunner config as per v0.16.0 - do not specify iceTransportPolicy to make it work with Firefox - mention managed mode steps in the README - improve README formatting Tested on k8s v1.27 (minikube & GKE autopilot).
So far we have added a 5 sec delay before sending our config deletion messages on the CDS server watchers in order to prevent a race condition where a terminating client receives the config deletion message from the CDS server before it can actually enter the graceful shutdown cycle, which causes the immediate dropping of all active client connections. The delay allowed comfortable time to the client to start graceful shutdown. Unfortunately, the delay also caused unexpected resets in some hard-to-debug situations, where during adding the Gateway API resources there is a transient that causes a (delayed) delete due to a missing API resource, which then resets the full config later when all resources become available. This change removes the delay in the config-delete path of the CDS server, so all config-delete updates are immediately sent out. In order to prevent the race condition, the CDS client in stunnerd ignores delete-config CDS updates all together (but only in stunnerd, the auth-service and stunnerctl still process them): once started, there is no other way to stop a stunnerd pod than to delete the Gateway resource.
Signed-off-by: Kornel David <[email protected]>
Signed-off-by: Emmanuel Ferdman <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.