Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: Securing a chart repository (AuthN) #1038

Closed
mumoshu opened this issue Aug 10, 2016 · 27 comments
Closed

feat: Securing a chart repository (AuthN) #1038

mumoshu opened this issue Aug 10, 2016 · 27 comments

Comments

@mumoshu
Copy link
Contributor

@mumoshu mumoshu commented Aug 10, 2016

Hi, Thanks as always for providing a great OSS 馃憤

While reading the documentation about chart repositories, it was not clear for me how to secure a chart repository.
Also I couldn't find any code in helm that provides authentication for connecting chart repositories.
Is there any plan to add it?

@technosophos
Copy link
Member

@technosophos technosophos commented Aug 10, 2016

On security:

  • For over-the-wire encryption, Helm can support HTTPS.
  • For authentication and authorization, we don't yet have anything enabled.

We are open to including authentication support in the Helm client. What kind of authentication are you interested in seeing added?

@mumoshu
Copy link
Contributor Author

@mumoshu mumoshu commented Aug 11, 2016

@technosophos Thank you for being so responsive 馃嵑

I'd like to see Digest Authentication support in the Helm client, so that we can:

  1. Authenticate without repeatedly sending username/password for each request like Basic Authentication does,
  2. (Optionally) expire sessions after some period of time(e.g. using Apache's AuthDigestNonceLifetime. Can't be done with Basic Auth)
  3. (Optionally) authorize access to a file according to whom it is accessed by(on the chart repository side, using digest auth's realm and username)
  4. Easily test secured chart repositories with curl --anyauth --user <user>:<pass> or other common tools
  5. Major http servers supports it(apache, nginx, lighthttpd, etc) so it won't be too hard for us to build our own secured chart repos.

IMHO,

  • Basic Authentication is too insecure, as chart repositories are not required to be https.
  • Rolling our own token/cookie-based authentication is overkill
@Thermi
Copy link

@Thermi Thermi commented Aug 14, 2016

I would like to weigh in on this.
IMHO, additionally to digest authentication, basic authentication and TLS client certificate authentication should be usable. The latter one would be relatively easy to implement, as it's just two additonal options (one for the certificate, one for the key) and some code to pass those two to the call that makes the TLS connection to the server.
I would strongly prefer TLS client authentication, as any enterprise should run its own PKI to secure internal services and it's sufficiently easy to implement even for private users or OSS projects.

@mumoshu
Copy link
Contributor Author

@mumoshu mumoshu commented Aug 15, 2016

@Thermi I totally agree with you about the client certificate authentication. Ideally, If I can choose digest or client certification authentication, I would definitely go with the latter.

Also, from an user's perspective, I believe it is not that hard to establish your own PKI today using OSS like vault and then authenticating clients and terminating TLS in front of the chart repository with ghostunnel.

@technosophos technosophos changed the title Securing a chart repository? feat: Securing a chart repository (AuhN) Aug 15, 2016
@technosophos technosophos changed the title feat: Securing a chart repository (AuhN) feat: Securing a chart repository (AuthN) Aug 15, 2016
@technosophos
Copy link
Member

@technosophos technosophos commented Aug 17, 2016

How do we want to bubble this up to the user? Do we want to interactively prompt for auth? For cert, should we support it in the Helm config file in $HELM_HOME?

@Thermi
Copy link

@Thermi Thermi commented Aug 17, 2016

I think there should be a user specific configuration file (~/.config/helm/config?) or a parameter to pass a configuration file (That would be much better, because one could change the configuration file between fetching parts from different chart servers) that contains a yaml structure, which holds...

  • the path to the certificate
  • the path to the key
  • an option for the password for the key (none (default, no password is on the key), prompt (ask the user for the password for the key), config (if this is set, the password is expected to be in another file)
@crestenstclair
Copy link

@crestenstclair crestenstclair commented Sep 2, 2016

I'm trying to use a GCE bucket to store my helm charts. Having a plugin API that allows people to write individual providers similar to how hashicorp's terraform makes a lot of sense.

@technosophos
Copy link
Member

@technosophos technosophos commented Sep 19, 2016

I like the idea of doing this in a pluggable way.

@technosophos
Copy link
Member

@technosophos technosophos commented Sep 26, 2016

@philips Any thoughts about whether this is something your team could spearhead? I know you guys have both strong background in this issue, and some viable use cases.

@technosophos technosophos added this to the 2.1.0-Alpha.1 milestone Oct 7, 2016
@klizhentas
Copy link

@klizhentas klizhentas commented Oct 31, 2016

we are currently migrating to helm and authentication is something we are currently looking at. Can we simply mirror kubectl authentication mechanisms or even as an option using ./kube/config client credentials? this will allow us to transparently use Helm without adding another authentication mechanisms.

@philips
Copy link
Contributor

@philips philips commented Nov 22, 2016

@technosophos @klizhentas See the discussion on sig-apps about leveraging the existing model used for Container Images: https://groups.google.com/forum/#!topic/kubernetes-sig-apps/R4H99dwZCQY

@micahhausler
Copy link

@micahhausler micahhausler commented Dec 4, 2016

This might be more a separate issue, but an S3 repo store + IAM auth would be fantastic. I'm all for pluggable auth

@technosophos
Copy link
Member

@technosophos technosophos commented Dec 19, 2016

Right now, the following efforts are ongoing for providing secure access to Helm repositories:

  1. There has been work to add SSL client auth support. I believe the PR for that will reappear in the queue shortly.
  2. The Helm plugin system was released in 2.1.0. This is the preferred route for implementing this feature
  3. Simple token auth and http basic auth are still on the table, though nobody is working on them

With plugins, authentication is implemented by the plugin, and Helm commands are wrapped inside. For example helm s3 fetch might handle IAM-based auth to S3 (as @micahhausler desires).

@libesz
Copy link
Contributor

@libesz libesz commented Feb 15, 2017

I would like to use OpenStack Swift object store as a Chart repo. Not familiar with the S3 in details, but I guess it is stg similar. Swift uses token based authentication in a form of http headers. Some details here.
If the downloader package would be somehow pluggable with customized http/generic clients here, that would ease the development of downloader plugins which on the other hand reuse the logic behind the downloader/manager/resolver package.
Should I open a new issue for this specific improvement?

@technosophos
Copy link
Member

@technosophos technosophos commented Feb 15, 2017

As of Helm 2.2.0, client-side SSL auth to a repository is now supported.

For special authentication protocols (S3, GCS, Swift), these should be done as plugins.

@libesz
Copy link
Contributor

@libesz libesz commented Feb 17, 2017

Agreed. Maybe my wording was bad. I would create the swift version of the chart downloader in a standalone/plugin manner. But isn't it so that if I want to be aligned with the helm behavior (which is in case of chart fetching the dependency resolution logic, downloading also the subcharts, respecting the directory structure, etc.), the best way is to import and reuse some packages from the core helm codebase.

I would like to only open up some pkg for reuse in alternative chart downloaders. Or did I misunderstand the concept?

@technosophos
Copy link
Member

@technosophos technosophos commented Feb 28, 2017

Yeah, that is something we're interested in doing.

@r351574nc3
Copy link

@r351574nc3 r351574nc3 commented Mar 5, 2017

@technosophos Is there documentation on how to use that? How do I define this with helm repo add?

@yongzhang
Copy link

@yongzhang yongzhang commented Mar 6, 2017

@technosophos

"As of Helm 2.2.0, client-side SSL auth to a repository is now supported." -- Where can I find the documents to config this?

@hydradan
Copy link

@hydradan hydradan commented Apr 25, 2017

For anyone else looking for docs, we now have the following options (helm repo add --help ):

      --ca-file string     verify certificates of HTTPS-enabled servers using this CA bundle
      --cert-file string   identify HTTPS client using this SSL certificate file
      --key-file string    identify HTTPS client using this SSL key file
@yongzhang
Copy link

@yongzhang yongzhang commented Apr 25, 2017

@hydradan Thanks, that's good.

@bakkerpeter
Copy link

@bakkerpeter bakkerpeter commented Oct 7, 2017

Anyone who is looking for a S3 plugin: https://github.com/hypnoglow/helm-s3
I haven't tested it but looks promising

@bacongobbler
Copy link
Member

@bacongobbler bacongobbler commented Oct 31, 2017

chartmuseum also has documentation on basic authentication support for chart repositories. Same with CoreOS' app registry via helm registry login.

Given that there are multiple reference implementations, I think this can be closed as resolved via documentation supplied by the auth plugins and chart repositories.

@bacongobbler
Copy link
Member

@bacongobbler bacongobbler commented Dec 15, 2020

The official URL is https://helm.sh/docs/topics/chart_repository/, FYI. We try to avoid linking straight to the documentation鈥檚 source code. It tends to be shifted around. But the URLs on helm.sh stay put.

@sbose78
Copy link
Contributor

@sbose78 sbose78 commented Dec 15, 2020

Thank you @bacongobbler , yes I did encounter broken URLs in a couple of places 馃摐 . Thank you for the tip, I'll make PRs chartmuseum/www#7 with the official docs home.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet