Support for multiple IPs for certificate of locally deployed KCP server

[doru1004]

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

[pdettori]

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.

[pdettori]

Should the workspace controller be updating the status of each workspace based on the IP bound by kcp at startup ?

[stevekuznetsov]

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

[pdettori]

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)

[pdettori]

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 ?

[pdettori]

I have opened issue #1471 to document that issue

[pdettori]

Also created a PR https://github.com/kcp-dev/kubernetes/pull/80 to address it

[kcp-ci-bot]

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

[kcp-ci-bot]

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

[kcp-ci-bot]

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]

@kcp-ci-bot: Closing this issue.

In response to [this](https://github.com/kcp-dev/kcp/issues/1452#issuecomment-2163849574): >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](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.