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 · 23 comments

Comments

Projects
None yet
@mumoshu
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@technosophos

technosophos Aug 10, 2016

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@mumoshu

mumoshu Aug 11, 2016

Contributor

@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
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@Thermi

Thermi 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.

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

This comment has been minimized.

Show comment
Hide comment
@mumoshu

mumoshu Aug 15, 2016

Contributor

@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.

Contributor

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 from Securing a chart repository? to feat: Securing a chart repository (AuhN) Aug 15, 2016

@technosophos technosophos changed the title from feat: Securing a chart repository (AuhN) to feat: Securing a chart repository (AuthN) Aug 15, 2016

@technosophos

This comment has been minimized.

Show comment
Hide comment
@technosophos

technosophos Aug 17, 2016

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@Thermi

Thermi 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)

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)
@honkycat

This comment has been minimized.

Show comment
Hide comment
@honkycat

honkycat 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.

honkycat 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

This comment has been minimized.

Show comment
Hide comment
@technosophos

technosophos Sep 19, 2016

Member

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

Member

technosophos commented Sep 19, 2016

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

@technosophos

This comment has been minimized.

Show comment
Hide comment
@technosophos

technosophos Sep 26, 2016

Member

@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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@klizhentas

klizhentas 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.

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

This comment has been minimized.

Show comment
Hide comment
@philips

philips Nov 22, 2016

Contributor

@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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@micahhausler

micahhausler 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

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

This comment has been minimized.

Show comment
Hide comment
@technosophos

technosophos Dec 19, 2016

Member

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).

Member

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

This comment has been minimized.

Show comment
Hide comment
@libesz

libesz Feb 15, 2017

Contributor

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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@technosophos

technosophos Feb 15, 2017

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@libesz

libesz Feb 17, 2017

Contributor

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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@technosophos

technosophos Feb 28, 2017

Member

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

Member

technosophos commented Feb 28, 2017

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

@r351574nc3

This comment has been minimized.

Show comment
Hide comment
@r351574nc3

r351574nc3 Mar 5, 2017

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

r351574nc3 commented Mar 5, 2017

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

@hiscal2015

This comment has been minimized.

Show comment
Hide comment
@hiscal2015

hiscal2015 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?

hiscal2015 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

This comment has been minimized.

Show comment
Hide comment
@hydradan

hydradan 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

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
@hiscal2015

This comment has been minimized.

Show comment
Hide comment
@hiscal2015

hiscal2015 Apr 25, 2017

@hydradan Thanks, that's good.

hiscal2015 commented Apr 25, 2017

@hydradan Thanks, that's good.

@bakkerpeter

This comment has been minimized.

Show comment
Hide comment
@bakkerpeter

bakkerpeter 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

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

This comment has been minimized.

Show comment
Hide comment
@bacongobbler

bacongobbler Oct 31, 2017

Member

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.

Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment