Skip to content

Add cluster-identity#429

Merged
mjudeikis merged 2 commits into
kbind-dev:mainfrom
mjudeikis:identity.add
Dec 24, 2025
Merged

Add cluster-identity#429
mjudeikis merged 2 commits into
kbind-dev:mainfrom
mjudeikis:identity.add

Conversation

@mjudeikis

@mjudeikis mjudeikis commented Dec 23, 2025

Copy link
Copy Markdown
Contributor

Summary

Re-add cluster-identity as a binding request. This would allow pre-provisioning of right identity namespaces based on cluster identity, rather than user identity (as it is now).

This is a temporary solution until we can sort this out in a more sustainable way. Its bit hacky.

What Type of PR Is This?

/kind regression
/kind bug

Related Issue(s)

Fixes #

Release Notes

Re-add cluster identity 

Comment thread cli/pkg/kubectl/bind-apiservice/cmd/cmd.go
coderabbitai[bot]
coderabbitai Bot previously approved these changes Dec 23, 2025
@mjudeikis mjudeikis force-pushed the identity.add branch 4 times, most recently from f7984df to 2456887 Compare December 23, 2025 14:04
@mjudeikis mjudeikis marked this pull request as ready for review December 23, 2025 14:04
@mjudeikis mjudeikis requested a review from a team as a code owner December 23, 2025 14:04

@ntnn ntnn left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we are creating one namespace per author/"consumer" to store the cluster objects?
I wonder if it wouldn't be safer to make the namespace deterministic instead of using generateName, e.g. kube-clusters-{identity-hash}; that would prevent things like one identity "owning" multiple namespaces.

Edit: I wouldn't change the namespace handling in this PR. We can adjust that later; just came to mind while reading the code.

// +kubebuilder:validation:Required
TemplateRef APIServiceExportTemplateRef `json:"templateRef"`
// ClusterIdentity contains information that uniquely identifies the cluster.
// When doing dry run, we expect the client to fill this field in (or it will be taked from local cluster where context is available).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
// When doing dry run, we expect the client to fill this field in (or it will be taked from local cluster where context is available).
// When doing dry run, we expect the client to fill this field in (or it will be taken from local cluster where context is available).

Comment on lines +37 to +38
identity string
author string

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Author is the user and identity is the cluster identity?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes.

Signed-off-by: Mangirdas Judeikis <mangirdas@judeikis.lt>
On-behalf-of: @SAP mangirdas.judeikis@sap.com
ntnn
ntnn previously approved these changes Dec 24, 2025
@mjudeikis

Copy link
Copy Markdown
Contributor Author

So we are creating one namespace per author/"consumer" to store the cluster objects? I wonder if it wouldn't be safer to make the namespace deterministic instead of using generateName, e.g. kube-clusters-{identity-hash}; that would prevent things like one identity "owning" multiple namespaces.

Edit: I wouldn't change the namespace handling in this PR. We can adjust that later; just came to mind while reading the code.

I think we can make this with this change too. Its kinda easy and either way - small breaking change.

@mjudeikis

mjudeikis commented Dec 24, 2025

Copy link
Copy Markdown
Contributor Author

made the ns static base36 change. same as kcp uses for logical clusters

@mjudeikis mjudeikis enabled auto-merge (squash) December 24, 2025 07:32
@mjudeikis mjudeikis merged commit fc3edfe into kbind-dev:main Dec 24, 2025
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants