kcp
kcp copied to clipboard
kcp-dev
Support for multiple IPs for certificate of locally deployed KCP server
I am running a KCP server locally but it seems that if I deploy the server and I am connected to a particular network, then that KCP server really only works when I am connected to that same network since the IP is connected to the certificate.
Is there a way (or a plan to add a way) to have multiple valid IPs associated with 1 certificate? Or maybe some other solution to this problem?
For example when I try to interact with the server after I redeploy it after changing networks I get:
Unable to connect to the server: x509: certificate is valid for X.X.X.X, not Y.Y.Y.Y
This is a duplicate of #1032. It looks like deleting .kcp/apiserver.{key,crt} as suggested there helps with re-generation of certs, however if there are existing workspaces they keep the old IP in the URL and they are no longer accessible without manually editing the admin.kubeconfig file.
Should the workspace controller be updating the status of each workspace based on the IP bound by kcp at startup ?
The GoDoc on clusterworkspaceshard.tenancy.kcp.dev field .spec.externalURL reads:
// ExternalURL is the externally visible address presented to users in Workspace URLs. // Changing this will break all existing workspaces on that shard, i.e. existing // kubeconfigs of clients will be invalid. Hence, when changing this value, the old // URL used by clients must keep working.
So, it seems like the reboot-into-a-new-IP case is not really something we want to support. I wonder if there's something we can do to make the dev ux here better?
/cc @sttts @csams
It looks like kcp start has an option to provide a hostname at startup --external-hostname. Perhaps it's just a matter of documenting the use of this flag for the situations where hostname is the same but the bound IP might change (e.g. because of a dev laptop connecting to a different network or because a machine)
I noted however that certificates are not signed for the hostname provided at startup with external-hostname, which is a different issue, so that would not work either at this time.
See https://github.com/kcp-dev/kubernetes/blob/feature-logical-clusters-1.23/pkg/genericcontrolplane/options/options.go#L128-L130
shouldn't the code above use the host name provided with --external-hostname instead of localhost if the external hostname is provided ?
Also created a PR https://github.com/kcp-dev/kubernetes/pull/80 to address it
Issues go stale after 90d of inactivity.
After a furter 30 days, they will turn rotten.
Mark the issue as fresh with /remove-lifecycle stale.
If this issue is safe to close now please do so with /close.
/lifecycle stale
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close
@kcp-ci-bot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopen. Mark the issue as fresh with/remove-lifecycle rotten./close
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.