Date   

Centralized Tiller deployments

sal
 

Hi,

I'm setting up a number of Kubernetes clusters and want to use Helm/Tiller to deploy charts. Let's call these clusters central, dev, stg, and prod.I'm wondering if it's possible to install Tiller into the central cluster and give it access to deploy into other clusters like dev, stg, and prod. That way I'm not duplicating charts across clusters. I imagine there would be some service account magic that would need to happen across clusters, but I'm not sure that tiller can access other clusters or if it's tied to single clusters.

Here's a diagram of what I'm trying to accomplish.


Re: Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@v1.4.0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

Matt Fisher <matt.fisher@...>
 

Sorry, first sentence meant to say `go mod` not dep.

 

From: Matthew Fisher <Matt.Fisher@...>
Date: Tuesday, April 16, 2019 at 7:57 AM
To: "soolaugust@..." <soolaugust@...>, "cncf-helm@..." <cncf-helm@...>
Subject: Re: [cncf-helm] Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

 

As far as we know, dep has a *lot* of issues when it comes to dependency resolution. Helm 2 uses glide, but Helm 3 uses dep. Both are being planned for deprecation (with the former being officially deprecated), but they’re still stable workhorses and will work in a production scenario. I’d suggest trying an alternative package manager entirely. `go mod` is still very early and is why we haven’t migrated over because of issues like this.

 

Matt

 

From: <cncf-helm@...> on behalf of "soolaugust via Lists.Cncf.Io" <soolaugust=gmail.com@...>
Reply-To: "soolaugust@..." <soolaugust@...>
Date: Monday, April 1, 2019 at 5:52 PM
To: "cncf-helm@..." <cncf-helm@...>
Cc: "cncf-helm@..." <cncf-helm@...>
Subject: [cncf-helm] Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

 

Hi all,

I want to build a Golang project with helm, but when I try to get helm package, I got following error:

go: github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

I google it and try to use "replace github.com/Sirupsen/logrus v1.4.0 => github.com/sirupsen/logrus v1.4.0" making package redirect to "sirupsen/logrus@....0". This problem solved but others following behind. I got a lot different errors when get other dependencies. 

So I want to know if helm package still be maintained. Thanks in advance :)


Re: Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@v1.4.0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

Matt Fisher <matt.fisher@...>
 

As far as we know, dep has a *lot* of issues when it comes to dependency resolution. Helm 2 uses glide, but Helm 3 uses dep. Both are being planned for deprecation (with the former being officially deprecated), but they’re still stable workhorses and will work in a production scenario. I’d suggest trying an alternative package manager entirely. `go mod` is still very early and is why we haven’t migrated over because of issues like this.

 

Matt

 

From: <cncf-helm@...> on behalf of "soolaugust via Lists.Cncf.Io" <soolaugust=gmail.com@...>
Reply-To: "soolaugust@..." <soolaugust@...>
Date: Monday, April 1, 2019 at 5:52 PM
To: "cncf-helm@..." <cncf-helm@...>
Cc: "cncf-helm@..." <cncf-helm@...>
Subject: [cncf-helm] Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

 

Hi all,

I want to build a Golang project with helm, but when I try to get helm package, I got following error:

go: github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"

I google it and try to use "replace github.com/Sirupsen/logrus v1.4.0 => github.com/sirupsen/logrus v1.4.0" making package redirect to "sirupsen/logrus@....0". This problem solved but others following behind. I got a lot different errors when get other dependencies. 

So I want to know if helm package still be maintained. Thanks in advance :)


Go get k8s.io/helm/pkg/helm meet ERROR "github.com/Sirupsen/logrus@v1.4.0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus""

soolaugust@...
 

Hi all,

I want to build a Golang project with helm, but when I try to get helm package, I got following error:
go: github.com/Sirupsen/logrus@....0: parsing go.mod: unexpected module path "github.com/sirupsen/logrus"
I google it and try to use "replace github.com/Sirupsen/logrus v1.4.0 => github.com/sirupsen/logrus v1.4.0" making package redirect to "sirupsen/logrus@....0". This problem solved but others following behind. I got a lot different errors when get other dependencies. 

So I want to know if helm package still be maintained. Thanks in advance :)


Re: Helm Question: Provide Helm Install flags using client.go

Matt Fisher <matt.fisher@...>
 

Ante,

This has been common feedback from other Helm users as well. Currently those flags and functions are intentionally hidden away in the `cmd` package, which is an internal package and cannot be imported outside of the helm project.

For reference, A similar comment was made in https://github.com/helm/helm/issues/5311. In the past, the internals of the `cmd` package changed very often due to breaking changes in `k8s.io/kubernetes`, which is why we have avoided migrating these functions to the `pkg` package in the past.

You may wish to take a look at https://github.com/helm/helm/pull/5365 which refactors most of the internal code for Helm 3, including splitting out the feature flags into the action package (new for Helm 3). While that won't help you in the short term, I just wanted to point it out that we are working on making this easier to maintain in the future and to expose more of the `cmd` package's internals for other projects to take advantage of.

In the meantime, you'll have to copy that code over to your project and maintain it yourself. It's too significant of an overhaul to make that change in Helm 2 and maintain backwards compatibility, which is why we're opting to do the work for Helm 3.

Hope that helps!


1504220459230_microsoft.png

Matthew Fisher

Caffeinated Software Engineer

Microsoft Canada


From: cncf-helm@... <cncf-helm@...> on behalf of via Lists.Cncf.Io <ante.peric1990=gmail.com@...>
Sent: Monday, March 11, 2019 6:18 AM
To: cncf-helm@...
Cc: cncf-helm@...
Subject: [cncf-helm] Helm Question: Provide Helm Install flags using client.go
 
Hi,

I've received your contact through the following discussion: https://discuss.kubernetes.io/t/provide-helm-install-flags-using-client-go/5415

I'm pasting the question from discussion so you can hopefully help me.

Also, I would be very grateful if somebody can send me Slack invite (if it works that way) once Slack is up&running (I presume you're quite busy w/ this at the moment)

Thanks,
Ante

---------------------------------------------------------------------------------------------

Hi all,

This is my first post here. I wanted to ask this question in slack group but invites are currently down (maybe someone can send me invite or I can ask on another channel? I’m quite new to slack so don’t know how this plays along :) ) and I was redirected here by http://slack.k8s.io/

Also, I’m not sure if this is the correct category to ask this question so someone can maybe help to get the post redirected (if needed).

Anyways, I’m creating a small orchestration tool in Go which includes K8s and Helm. This tool makes use of helm/client.go to perform helm install. In my install I need to support several flags, including –values, --set and -f (users provide it from different sources so can’t modify the logic on user end). I’ve noticed that InstallRelease() function doesn’t allow me to separately specify –values and –set/-f combinations as command line usually does. The method allows me to specify InstallOption.ValueOverrides(data), where I need to manually merge the above flag values in order to create the data parameter. As I would prefer not to do this, I checked the install.go file (this one is executed via helm command line) and it has functions called vals() and mergeFlags(). Unfortunately, these are private so can’t use them to assemble the data above.

Therefore, I’m stuck on both ends and can’t do anything neat (without actually hacking it)

Can someone maybe help with this issue or provide suggestion?

Thanks,
Ante


Helm Question: Provide Helm Install flags using client.go

Ante Peric <ante.peric1990@...>
 

Hi,

I've received your contact through the following discussion: https://discuss.kubernetes.io/t/provide-helm-install-flags-using-client-go/5415

I'm pasting the question from discussion so you can hopefully help me.

Also, I would be very grateful if somebody can send me Slack invite (if it works that way) once Slack is up&running (I presume you're quite busy w/ this at the moment)

Thanks,
Ante

---------------------------------------------------------------------------------------------

Hi all,

This is my first post here. I wanted to ask this question in slack group but invites are currently down (maybe someone can send me invite or I can ask on another channel? I’m quite new to slack so don’t know how this plays along :) ) and I was redirected here by http://slack.k8s.io/

Also, I’m not sure if this is the correct category to ask this question so someone can maybe help to get the post redirected (if needed).

Anyways, I’m creating a small orchestration tool in Go which includes K8s and Helm. This tool makes use of helm/client.go to perform helm install. In my install I need to support several flags, including –values, --set and -f (users provide it from different sources so can’t modify the logic on user end). I’ve noticed that InstallRelease() function doesn’t allow me to separately specify –values and –set/-f combinations as command line usually does. The method allows me to specify InstallOption.ValueOverrides(data), where I need to manually merge the above flag values in order to create the data parameter. As I would prefer not to do this, I checked the install.go file (this one is executed via helm command line) and it has functions called vals() and mergeFlags(). Unfortunately, these are private so can’t use them to assemble the data above.

Therefore, I’m stuck on both ends and can’t do anything neat (without actually hacking it)

Can someone maybe help with this issue or provide suggestion?

Thanks,
Ante


Re: Status update for Helm 3 repos

Matt Butcher <matt.butcher@...>
 

Now that Hub is there, I think it may end up being more useful than `helm search`. Right now, `helm search` ONLY searches the local cache of a repo. So it's sort of under-powered as is.


From: cncf-helm@... <cncf-helm@...> on behalf of Josh Dolitsky via Lists.Cncf.Io <jdolitsky=gmail.com@...>
Sent: Monday, March 4, 2019 2:44:06 PM
To: cncf-helm@...
Cc: cncf-helm@...
Subject: Re: [cncf-helm] Status update for Helm 3 repos
 
Mentioned in my message above is "helm search" work for Helm 3.. Out of curiosity, does anyone normally use the "helm search" command to search for charts?
I usually obtain the chart string ahead of time from Hub (where you can search) or from a git readme, or as part of some ci/cd flow, etc.

On Fri, Feb 8, 2019 at 3:16 PM Josh Dolitsky <jdolitsky@...> wrote:

Over the past several months, we have been working on putting together some changes that would allow users to store their Helm charts in container registries.

The level of collaboration has been pretty incredible, and has involved working with several groups and individuals outside of Helm, including CNAB and OCI. Steve Lasker has really kept the conversation alive, bringing a variety of groups to the table, and Jimmy Zelinskie has acted as liaison to the larger container ecosystem, making sure we are aligned with OCI. They and countless others in the community have also been involved in making this come to life  - thank you all!

This week, we have merged the first set of changes related to this into the Helm dev-v3 branch. Although the initial release of Helm 3.0 is still a ways away, if you're interested in trying out the new registry-related features, I've put together this doc with some examples: https://github.com/jdolitsky/helm3-registry-intro

The new functionality looks like something this:
$ helm chart list
REF                                                     NAME                    VERSION DIGEST  SIZE            CREATED
localhost:5000/myrepo/mychart:latest                    mychart                 2.7.1   84059d7 454 B           27 seconds
localhost:5000/stable/acs-engine-autoscaler:latest      acs-engine-autoscaler   2.2.2   d8d6762 4.3 KiB         2 hours
localhost:5000/stable/aerospike:latest                  aerospike               0.2.1   4aff638 3.7 KiB         2 hours
localhost:5000/stable/airflow:latest                    airflow                 0.13.0  c46cc43 28.1 KiB        2 hours
localhost:5000/stable/anchore-engine:latest             anchore-engine          0.10.0  3f3dcd7 34.3 KiB        2 hours
...
You may also be interested in the following blog posts which provide some great background on this subject:
We are still working with OCI to come up with a final spec for how to appropriately store artifacts such as Helm charts in a registry. We are also likely to make some modifications to the UX for the new commands (e.g. "helm push" vs "helm chart push" etc.). In addition, we still need to tackle authentication ("helm login") and remote search ("helm search").

If you have any ideas and/or special requirements for this, now is the time to reach out! Looking forward to seeing the end result of this stuff in Helm 3.

Thanks,

Josh



Re: Status update for Helm 3 repos

Josh Dolitsky
 

Mentioned in my message above is "helm search" work for Helm 3.. Out of curiosity, does anyone normally use the "helm search" command to search for charts?
I usually obtain the chart string ahead of time from Hub (where you can search) or from a git readme, or as part of some ci/cd flow, etc.


On Fri, Feb 8, 2019 at 3:16 PM Josh Dolitsky <jdolitsky@...> wrote:
Over the past several months, we have been working on putting together some changes that would allow users to store their Helm charts in container registries.

The level of collaboration has been pretty incredible, and has involved working with several groups and individuals outside of Helm, including CNAB and OCI. Steve Lasker has really kept the conversation alive, bringing a variety of groups to the table, and Jimmy Zelinskie has acted as liaison to the larger container ecosystem, making sure we are aligned with OCI. They and countless others in the community have also been involved in making this come to life  - thank you all!

This week, we have merged the first set of changes related to this into the Helm dev-v3 branch. Although the initial release of Helm 3.0 is still a ways away, if you're interested in trying out the new registry-related features, I've put together this doc with some examples: https://github.com/jdolitsky/helm3-registry-intro

The new functionality looks like something this:
$ helm chart list
REF                                                     NAME                    VERSION DIGEST  SIZE            CREATED
localhost:5000/myrepo/mychart:latest                    mychart                 2.7.1   84059d7 454 B           27 seconds
localhost:5000/stable/acs-engine-autoscaler:latest      acs-engine-autoscaler   2.2.2   d8d6762 4.3 KiB         2 hours
localhost:5000/stable/aerospike:latest                  aerospike               0.2.1   4aff638 3.7 KiB         2 hours
localhost:5000/stable/airflow:latest                    airflow                 0.13.0  c46cc43 28.1 KiB        2 hours
localhost:5000/stable/anchore-engine:latest             anchore-engine          0.10.0  3f3dcd7 34.3 KiB        2 hours
...
You may also be interested in the following blog posts which provide some great background on this subject:
We are still working with OCI to come up with a final spec for how to appropriately store artifacts such as Helm charts in a registry. We are also likely to make some modifications to the UX for the new commands (e.g. "helm push" vs "helm chart push" etc.). In addition, we still need to tackle authentication ("helm login") and remote search ("helm search").

If you have any ideas and/or special requirements for this, now is the time to reach out! Looking forward to seeing the end result of this stuff in Helm 3.

Thanks,

Josh



Re: Recurring Helm 3 repos meeting

Josh Dolitsky
 

I'm going ahead and cancelling the weekly repos call. We have had initial set of changes related to this merged last week, and we can continue to iterate from there. If we have additional things to discuss, we can talk about it in the Thursday calls or have one-offs.
Thanks everyone who participated in these discussions!

Josh


Status update for Helm 3 repos

Josh Dolitsky
 

Over the past several months, we have been working on putting together some changes that would allow users to store their Helm charts in container registries.

The level of collaboration has been pretty incredible, and has involved working with several groups and individuals outside of Helm, including CNAB and OCI. Steve Lasker has really kept the conversation alive, bringing a variety of groups to the table, and Jimmy Zelinskie has acted as liaison to the larger container ecosystem, making sure we are aligned with OCI. They and countless others in the community have also been involved in making this come to life  - thank you all!

This week, we have merged the first set of changes related to this into the Helm dev-v3 branch. Although the initial release of Helm 3.0 is still a ways away, if you're interested in trying out the new registry-related features, I've put together this doc with some examples: https://github.com/jdolitsky/helm3-registry-intro

The new functionality looks like something this:
$ helm chart list
REF                                                     NAME                    VERSION DIGEST  SIZE            CREATED
localhost:5000/myrepo/mychart:latest                    mychart                 2.7.1   84059d7 454 B           27 seconds
localhost:5000/stable/acs-engine-autoscaler:latest      acs-engine-autoscaler   2.2.2   d8d6762 4.3 KiB         2 hours
localhost:5000/stable/aerospike:latest                  aerospike               0.2.1   4aff638 3.7 KiB         2 hours
localhost:5000/stable/airflow:latest                    airflow                 0.13.0  c46cc43 28.1 KiB        2 hours
localhost:5000/stable/anchore-engine:latest             anchore-engine          0.10.0  3f3dcd7 34.3 KiB        2 hours
...
You may also be interested in the following blog posts which provide some great background on this subject:
We are still working with OCI to come up with a final spec for how to appropriately store artifacts such as Helm charts in a registry. We are also likely to make some modifications to the UX for the new commands (e.g. "helm push" vs "helm chart push" etc.). In addition, we still need to tackle authentication ("helm login") and remote search ("helm search").

If you have any ideas and/or special requirements for this, now is the time to reach out! Looking forward to seeing the end result of this stuff in Helm 3.

Thanks,

Josh



Re: Security release of ChartMuseum v0.8.1

Matt Farina
 

A CVE id has been assigned for this vulnerability as CVE-2019-1000009.

-- 
Matt Farina
mattfarina.com



On Jan 14, 2019, at 3:04 PM, Matthew Farina <matt@...> wrote:

A security vulnerability was discovered in ChartMuseum. The following details can be found on the Helm blog  the root source for this disclosure, but are reproduced here as well.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in ChartMuseum, impacting all versions of ChartMuseum between ChartMuseum >=0.1.0 and < 0.8.1. A specially crafted chart could be uploaded that caused the uploaded archive to be saved outside of the intended location.

When ChartMuseum is configured for multitenancy the specially crafted chart could be uploaded to one tenant but saved in the location of another tenant. This includes overwriting a chart at a version in the other tenant.

Additionally, if ChartMusem is configured to use a file system the uploaded Chart archive may be uploaded to locations outside of the storage directory. It could be uploaded to any place the ChartMuseum application binary has write permission to.

We are unaware of any public exploits caused by this issue.

Details

When a chart archive is uploaded the name of the chart, as listed in the `Chart.yaml` file, is used when creating the path location to save the file. The name is joined with the directory or object storage prefix path. The chart name was not sanitized or validated. This allowed directory traversal characters, such as `../..`, to be used in the name and affect the directory the archive file is saved within.

When the Helm client creates a chart archive, via the `helm package` command, it validates that the chart name and encapsulating directory match. It will not generate a chart archive with directory traversal characters.

Fix

Update to ChartMuseum >= 0.8.1

To prevent this from happening, ChartMuseum now checks the name of the chart to make sure there are no directory traversal characters in the name before using it to save the archive. If the name contains directory traversal characters the API will return a 400 Bad Request response and message to signify the name issue.

-- 
Matt Farina
mattfarina.com





Re: Security release of Helm Client v2.12.2

Matt Farina
 

A CVE id for this vulnerability has been assigned as CVE-2019-1000008.

-- 
Matt Farina
mattfarina.com



On Jan 14, 2019, at 3:04 PM, Matt Farina <matt@...> wrote:

A security vulnerability was discovered in Helm, the cli. The following details can be found on the Helm blog  the root source for this disclosure, but are reproduced here as well.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in the Helm client, impacting all versions of Helm between Helm >=2.0.0 and < 2.12.2. Two Helm client commands may be coerced into unpacking unsafe content from a maliciously designed chart.

A specially crafted chart may be able to unpack content into locations on the filesystem outside of the chart’s path, potentially overwriting existing files.

No version of Tiller is known to be impacted. This is a client-only issue.

The following Helm commands may unsafely unpack malformed charts onto a local folder: `helm fetch –untar` and `helm lint some.tgz`.

We are unaware of any public exploits caused by this issue.

Details

During unpacking operations, file names were not checked to see if they contained references to parent directories. Normally, this does not impact Helm’s operation because file names are only used as in-memory names. However, two operations were found to export files directly to disk without sanitizing the file names. The `helm lint` command may unpack a tar archive into a temporary directory, and `helm fetch --untar` will unpack an archive into a user-supplied directory. In both cases, not all file names were correctly sanitized.

No Tiller version is impacted. This vulnerability does not render clusters vulnerable to attack. Tiller does not store unpacked charts. All charts are loaded in-memory, and paths are resolved as string names, not as locations on a file system.

Workarounds

Unpack charts with the appropriate `tar` command, and do not use the `--untar` flag on `helm fetch`. Do not run `helm lint` on tars. Unpack them manually and run `helm lint` on the unpacked directory.

Fix

Update to Helm >= 2.12.2.

As of Helm 2.12.2, the unpacking operation disallows paths that could be used to store files outside of the present working directory. This is considered a bug fix, rather than a breaking change, because there is no way to produce such malformed packages from within Helm or from standard chart-building tools.

From Helm 2.12.2 onward, charts that contain files that are not relative to the current working directory will fail to load, even when loaded into memory.


-- 
Matt Farina
mattfarina.com





Tiller can't init dew to lack of permissions

Domingo Muñoz Daza <domingo.munoz@...>
 

Hello, first time using helm in our kubernetes cluster and we came accross some issue, and I was hoping you could help us. I don't know if this is the right way to contact the Helm community.

Output of `helm version`:

`Client: &version.Version{SemVer:"v2.12.3", GitCommit:"eecf22f77df5f65c823aacd2dbd30ae6c65f186e", GitTreeState:"clean"}
Error: could not find a ready tiller pod`

Output of `kubectl version`:

`Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.1", GitCommit:"eec55b9ba98609a46fee712359c7b5b365bdd920", GitTreeState:"clean", BuildDate:"2018-12-13T10:39:04Z", GoVersion:"go1.11.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.2-CCE2.0.7-B003", GitCommit:"302f471a1e2caa114c9bb708c077fbb363aa2f13", GitTreeState:"clean", BuildDate:"2018-06-20T03:27:16Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"}`

Cloud Provider/Platform (AKS, GKE, Minikube etc.): Open Telekom Cloud

I have created a tiller serviceaccount and its binded with cluster-admin clusterrole

The output of `kubectl get pods -n kube-system` is

Captura de pantalla 2019-02-06 a las 13.33.59.png

The output of `kubectl describe pods tiller -n kube-system`

Captura de pantalla 2019-02-06 a las 13.34.09.png

Tried to get the logs from tiller and this was the output ` kubectl logs -f tiller-deploy-7c78f74c-7529q -n kube-system`

`[main] 2019/02/06 12:32:13 Cannot initialize Kubernetes connection: failed to read token file "/var/run/secrets/kubernetes.io/serviceaccount/token": open /var/run/secrets/kubernetes.io/serviceaccount/token: permission denied``

Can't access the container to check this path because its not created yet. Any thoughts on this?


Does Redis HA Helm Chart ensure that the endpoint picked by the service is always the master

noel.varghese.22@...
 

Hey was trying to deploy a redis cluster on top of openshift/kubernetes, looked at a dozen examples, but in my usecase the client can only connect to a master host and port. 

Recently came across this helm chart => https://github.com/helm/charts/tree/master/stable/redis-ha
If there is someone who has knowledge about redis can they take a look at the yaml files and tell me that if I try connecting using the headless service hostname, will I always connect to  the master redis node. Or if it is even possible to achieve that in openshift/kubernetes. i.e a highly available redis connection url , no matter what happens to the pods, after the sentinel handle the failovers, the redis ha service url and redis port should connect to the master everytime and not the redis instances in the cluster.


Kubernetes Beta APIs and Deprecation

Matt Farina
 

Please consider this email advanced warning. Just trying to give some of you a long lead time on making changes.

Back in Kuberentes 1.9 the workloads API reached GA with the apps/v1 API. Kubernetes deprecation policy notes that the beta API version can be removed after 3 releases or 9 months, which ever is longer.

For the Workloads API and some others, it has been much longer than 9 months and the beta APIs are still working, for now.

A plan is in place to stop accepting beta objects to the API for those that qualify for deprecation. This includes the the workloads API. The current plan puts this time as after Kubernetes 1.15, although it is subject to change. Existing objects stored in a cluster will continue to work. This is on the API accepting the beta objects.

So, this is a call to action. If you are using Beta APIs please update your chart templates to use the stable versions.

-- 
Matt Farina
mattfarina.com




Re: Security release of ChartMuseum v0.8.1

Josh Dolitsky
 

In a typical ChartMuseum installation, uploads are protected by a single basic auth username/password combo. In this scenario, anyone with this credential pair can upload chart packages to the wrong tenant, without using this vulnerability.

When using bearer/token auth, or when using ChartMuseum as a backend service, this issue may be more cause for concern.

Keep in mind, however, that this vulnerability also allows file uploads outside the storage root (depending on permissions and configuration).

If you have deployed ChartMuseum using the chartmuseum/chartmuseum Docker image, please upgrade to the following tag which contains the fix: v0.8.1

I've also put together a simple tool which can be used to verify that your systems have not been affected by this:

Apologies for any inconvenience this may cause. If you have any questions, please feel free to reach out to me directly on Slack/Twitter (@jdolitsky).

Thanks,
Josh Dolitsky

On Mon, Jan 14, 2019 at 2:04 PM Matt Farina <matt@...> wrote:
A security vulnerability was discovered in ChartMuseum. The following details can be found on the Helm blog  the root source for this disclosure, but are reproduced here as well.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in ChartMuseum, impacting all versions of ChartMuseum between ChartMuseum >=0.1.0 and < 0.8.1. A specially crafted chart could be uploaded that caused the uploaded archive to be saved outside of the intended location.

When ChartMuseum is configured for multitenancy the specially crafted chart could be uploaded to one tenant but saved in the location of another tenant. This includes overwriting a chart at a version in the other tenant.

Additionally, if ChartMusem is configured to use a file system the uploaded Chart archive may be uploaded to locations outside of the storage directory. It could be uploaded to any place the ChartMuseum application binary has write permission to.

We are unaware of any public exploits caused by this issue.

Details

When a chart archive is uploaded the name of the chart, as listed in the `Chart.yaml` file, is used when creating the path location to save the file. The name is joined with the directory or object storage prefix path. The chart name was not sanitized or validated. This allowed directory traversal characters, such as `../..`, to be used in the name and affect the directory the archive file is saved within.

When the Helm client creates a chart archive, via the `helm package` command, it validates that the chart name and encapsulating directory match. It will not generate a chart archive with directory traversal characters.

Fix

Update to ChartMuseum >= 0.8.1

To prevent this from happening, ChartMuseum now checks the name of the chart to make sure there are no directory traversal characters in the name before using it to save the archive. If the name contains directory traversal characters the API will return a 400 Bad Request response and message to signify the name issue.

-- 
Matt Farina
mattfarina.com




Security release of Helm Client v2.12.2

Matt Farina
 

A security vulnerability was discovered in Helm, the cli. The following details can be found on the Helm blog  the root source for this disclosure, but are reproduced here as well.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in the Helm client, impacting all versions of Helm between Helm >=2.0.0 and < 2.12.2. Two Helm client commands may be coerced into unpacking unsafe content from a maliciously designed chart.

A specially crafted chart may be able to unpack content into locations on the filesystem outside of the chart’s path, potentially overwriting existing files.

No version of Tiller is known to be impacted. This is a client-only issue.

The following Helm commands may unsafely unpack malformed charts onto a local folder: `helm fetch –untar` and `helm lint some.tgz`.

We are unaware of any public exploits caused by this issue.

Details

During unpacking operations, file names were not checked to see if they contained references to parent directories. Normally, this does not impact Helm’s operation because file names are only used as in-memory names. However, two operations were found to export files directly to disk without sanitizing the file names. The `helm lint` command may unpack a tar archive into a temporary directory, and `helm fetch --untar` will unpack an archive into a user-supplied directory. In both cases, not all file names were correctly sanitized.

No Tiller version is impacted. This vulnerability does not render clusters vulnerable to attack. Tiller does not store unpacked charts. All charts are loaded in-memory, and paths are resolved as string names, not as locations on a file system.

Workarounds

Unpack charts with the appropriate `tar` command, and do not use the `--untar` flag on `helm fetch`. Do not run `helm lint` on tars. Unpack them manually and run `helm lint` on the unpacked directory.

Fix

Update to Helm >= 2.12.2.

As of Helm 2.12.2, the unpacking operation disallows paths that could be used to store files outside of the present working directory. This is considered a bug fix, rather than a breaking change, because there is no way to produce such malformed packages from within Helm or from standard chart-building tools.

From Helm 2.12.2 onward, charts that contain files that are not relative to the current working directory will fail to load, even when loaded into memory.


-- 
Matt Farina
mattfarina.com




Security release of ChartMuseum v0.8.1

Matt Farina
 

A security vulnerability was discovered in ChartMuseum. The following details can be found on the Helm blog  the root source for this disclosure, but are reproduced here as well.

Security researcher Bernard Wagner of Entersekt discovered a vulnerability in ChartMuseum, impacting all versions of ChartMuseum between ChartMuseum >=0.1.0 and < 0.8.1. A specially crafted chart could be uploaded that caused the uploaded archive to be saved outside of the intended location.

When ChartMuseum is configured for multitenancy the specially crafted chart could be uploaded to one tenant but saved in the location of another tenant. This includes overwriting a chart at a version in the other tenant.

Additionally, if ChartMusem is configured to use a file system the uploaded Chart archive may be uploaded to locations outside of the storage directory. It could be uploaded to any place the ChartMuseum application binary has write permission to.

We are unaware of any public exploits caused by this issue.

Details

When a chart archive is uploaded the name of the chart, as listed in the `Chart.yaml` file, is used when creating the path location to save the file. The name is joined with the directory or object storage prefix path. The chart name was not sanitized or validated. This allowed directory traversal characters, such as `../..`, to be used in the name and affect the directory the archive file is saved within.

When the Helm client creates a chart archive, via the `helm package` command, it validates that the chart name and encapsulating directory match. It will not generate a chart archive with directory traversal characters.

Fix

Update to ChartMuseum >= 0.8.1

To prevent this from happening, ChartMuseum now checks the name of the chart to make sure there are no directory traversal characters in the name before using it to save the archive. If the name contains directory traversal characters the API will return a 400 Bad Request response and message to signify the name issue.

-- 
Matt Farina
mattfarina.com




Re: Helm on Maven Central

Laird Nelson
 

You might also be interested in microBean Helm (https://microbean.github.io/microbean-helm/) and/or the helm-maven-plugin (https://microbean.github.io/helm-maven-plugin/).

Best,
Laird
--

On Thu, Jan 3, 2019 at 8:34 AM Matt Fisher via Lists.Cncf.Io <matt.fisher=microsoft.com@...> wrote:

Hey Paul, there are no plans for making the Helm command-line binaries available on Maven Central, though I’m a little concerned about publishing helm binaries on Maven Central that are not published by Helm’s CI infrastructure. In the past we’ve considered anything that has not been released through Helm’s CI infrastructure as untrusted/unsafe (run at your own risk) as we can’t verify that the source code or the release assets themselves have not been tampered with.

 

Is there a particular reason why the releases available on GitHub won’t work in this case?

 

Matt

 

From: cncf-helm@... <cncf-helm@...> On Behalf Of Paul Vorbach
Sent: Thursday, January 3, 2019 2:12 AM
To: cncf-helm@...
Subject: [cncf-helm] Helm on Maven Central

 

Hello,

 

Are there any plans for making the Helm command-line binaries available on Maven Central? And if that's not the case, would you mind if we publish helm binaries on Maven Central?

 

We have a plugin for Maven that uses helm binaries we published to our internal company Nexus for easier management of different helm versions. We plan to open source this plugin and thus need to publish helm binaries to Maven Central.

 

Best regards,

Paul


Re: Helm on Maven Central

Matt Fisher <matt.fisher@...>
 

Hey Paul, there are no plans for making the Helm command-line binaries available on Maven Central, though I’m a little concerned about publishing helm binaries on Maven Central that are not published by Helm’s CI infrastructure. In the past we’ve considered anything that has not been released through Helm’s CI infrastructure as untrusted/unsafe (run at your own risk) as we can’t verify that the source code or the release assets themselves have not been tampered with.

 

Is there a particular reason why the releases available on GitHub won’t work in this case?

 

Matt

 

From: cncf-helm@... <cncf-helm@...> On Behalf Of Paul Vorbach
Sent: Thursday, January 3, 2019 2:12 AM
To: cncf-helm@...
Subject: [cncf-helm] Helm on Maven Central

 

Hello,

 

Are there any plans for making the Helm command-line binaries available on Maven Central? And if that's not the case, would you mind if we publish helm binaries on Maven Central?

 

We have a plugin for Maven that uses helm binaries we published to our internal company Nexus for easier management of different helm versions. We plan to open source this plugin and thus need to publish helm binaries to Maven Central.

 

Best regards,

Paul

281 - 300 of 458