The Kubernetes team needs a way to distribute internal Workshop SDKs across multiple repositories without making them publicly available. Currently, in-project SDKs work as a workaround but don't scale well. A private SDK mechanism in the SDK Store would solve this cleanly.
Background
We maintain a shared set of AI agent configs (prompts, workflows, tool definitions) in canonical/k8s-ai-agent-toolkit. This repo is private since it references undisclosed repositories, internal processes, and pre-release tooling. The goal is to have a consistent AI-assisted development experience across all Kubernetes team workshops.
Current Approach
I've packaged the toolkit as an in-project SDK following the Workshop docs. This works but requires replicating the SDK definition into every repository that consumes it. We have 10+ active repos, so we need to implement additional automation to maintain this.
What works:
- SDK definition and hooks function correctly as in-project SDKs
- Configs are not exposed publicly since they live in private repos
What doesn't work well:
- No single source of truth. Updates require syncing to all repos
- Automation overhead (copy scripts, submodules, or CI steps) to keep repos in sync
- Easy to drift when someone forgets to pull the latest version
Proposed Solution: Private SDKs
Publish SDKs to the SDK Store with restricted visibility. Same mechanics as public SDKs (channels, versioning, platform metadata) but access-controlled.
Requirements from our side:
- Restrict access to Canonical users (at minimum), ideally per-team or per-org
- Publish and update via
sdkcraft upload the same way public SDKs work
- Consume via
sdk: entries in workshop.yaml without special handling
- No changes to SDK definition format needed (visibility is a Store property, not a packaging one)
Benefits:
- Publish once, consume everywhere
- No sync scripts or submodules
- Sensitive references (internal repos, unreleased tooling) stay private
- Other teams with internal tooling SDKs get the same benefit
The Kubernetes team needs a way to distribute internal Workshop SDKs across multiple repositories without making them publicly available. Currently, in-project SDKs work as a workaround but don't scale well. A private SDK mechanism in the SDK Store would solve this cleanly.
Background
We maintain a shared set of AI agent configs (prompts, workflows, tool definitions) in canonical/k8s-ai-agent-toolkit. This repo is private since it references undisclosed repositories, internal processes, and pre-release tooling. The goal is to have a consistent AI-assisted development experience across all Kubernetes team workshops.
Current Approach
I've packaged the toolkit as an in-project SDK following the Workshop docs. This works but requires replicating the SDK definition into every repository that consumes it. We have 10+ active repos, so we need to implement additional automation to maintain this.
What works:
What doesn't work well:
Proposed Solution: Private SDKs
Publish SDKs to the SDK Store with restricted visibility. Same mechanics as public SDKs (channels, versioning, platform metadata) but access-controlled.
Requirements from our side:
sdkcraft uploadthe same way public SDKs worksdk:entries inworkshop.yamlwithout special handlingBenefits: