Comments (5)
To make it easy to reproduce and understand what needs to change in Helm, could you provide me with the following?
- Concrete steps to configure gitlab (or any other freely available repository) with path/scoped based authorisation
- Any reference (preferably an upstream issue/PR/documentation) of the Buildkit extension
I know this is non-standard from ~/.docker/config.json point of view
This might be a sticking point when deciding on whether to add this support or not, but I'll leave that for later discussions
from helm.
All this is based on standard containers/podman/buildah containers-auth.json:
https://github.com/containers/image/blob/main/docs/containers-auth.json.5.md#format
In Gitlab, create to separate repositories; e.g.
- gitlab.com/mygroup/myproject1
- gitlab.com/mygroup/myproject2
each of these provide namespace for OCI registry, e.g.:
- registry.gitlab.com/mygroup/myproject1/mychart1
- registry.gitlab.com/mygroup/myproject2/mychart2
You can create access tokens for registry pull from each of those repositories/registries (Settings/AccessTokens)
- https://gitlab.com/mygroup/myproject1/-/settings/access_tokens
- https://gitlab.com/mygroup/myproject2/-/settings/access_tokens
Hence, each of these repos/registries have different authentication tokens.
(Note: as regular user you may not be confronted with this issue, because you use your global personal authentication, and you have access to both repos with same authentication token. However, in CI/CD you typically don't use user authentication, you use group/project scoped auth. tokens.)
(Note2: you typically create tokens on group level, not project level. But you still need different tokens to different groups.)
Now, your local mychart3 may want to add dependency to both mychart1 and mychart2:
apiVersion: v2
name: mychart3
version 1.0.0
dependencies:
- name: mychart1
version: x
repository: oci://registry.gitlab.com/mygroup/myproject1
- name: mychart2
version: x
repository: oci://registry.gitlab.com/mygroup/myproject2
and your config.json would look like:
{"auths": {
"registry.gitlab.com": {"auth": "base64-encoded-token1"}
}}
^^ This is broken. There is nowhere to put token2 for access to myproject2. helm-dep-up will fail.
You want:
{"auths": {
"registry.gitlab.com/mygroup/myproject1": {"auth": "token1"},
"registry.gitlab.com/mygroup/myproject2": {"auth": "token2"}
}}
This is only way to use helm in this scenario. (Not only helm, but OCI registry in general.)
This is already prototyped/standardized by kubernetes/containers/podman/buildah/buildkit/etc...
from helm.
@patrikbeno i am going to do a bit of research into what options we would be able to provide and if any, what enhancements need to be made. I'll circle back after i have a bit more information on the topic at hand
from helm.
note this duplicate: #11286
from helm.
will close in favor of the existing issue. I think #11286 (comment) is still the current state
from helm.
Related Issues (20)
- go package for validate a values.yaml from a values.schema.json HOT 1
- Enhancement: Allow deep overriding of Values in a list using `-f values.yaml` the way it works with `--set` HOT 3
- Helm silently fails when templating/installing different versions of the same chart name. HOT 1
- Helm incorrect processes nodeSelecto with GPU Nodes HOT 1
- add / update Supported Kubernetes Versions page to have 3.15 version HOT 1
- Helm CLI should add "helm sink" to uninstall HOT 1
- Upgrade release with helm SDK got error: cannot patch "xxxx-deploy" with kind Deployment HOT 1
- Helm rollback with mismatch in resources with original and target revisions raises error. HOT 1
- can't use range inside library chart defined template in helm HOT 2
- helm upgrade --install Command Deletes All The Resources in Existing Release HOT 4
- Provide methods to disable OCI feature HOT 5
- In Helm 3.9, Default Values Were Used for Subcharts, But Helm 3.15 Raises Nil Pointer Error When Accessing Unset Values HOT 1
- wrong kubeversion detected HOT 6
- RFE: Support for multi-document values files HOT 7
- Warnings: Use tokens from the TokenRequest API or manually created secret-based tokens instead of auto-generated secret-based tokens. HOT 2
- Get more debug informations about why and upgrade failed with "release: already exists" HOT 2
- helm no strict version checking for dependencies
- templating is slower when using dependencies with tagged version HOT 2
- Concurrent `helm dependency build` fail due to race condition
- bug: go HTTPS_PROXY/NO_PROXY env vars are not respected when mTLS args specified on `helm install/upgrade`
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from helm.