spire
spire copied to clipboard
spiffe
Feature request: Adding a helm chart
I wanted to check if the spire project is interested in adding a helm chart. I started putting one together from the quick start, available at https://github.com/sudo-bmitch/helm-charts and would be happy to migrate this over to Spiffe. Is that something you'd be interested in, or is the "no official helm chart" comment on the installing page intentional rather than a developer time issue?
Hi @sudo-bmitch, thank you for opening this and sorry for the delay.
We're definitely interested in providing an "official" helm chart, but we have a lot of questions and we need help!
First, @marcofranssen has done a lot of work on building up and maintaining an "unofficial" SPIRE helm chart, you can find it here: https://artifacthub.io/packages/helm/philips-labs/spire .. I'm not sure how much overlap there is with your chart, but perhaps this is the best place to start, and it would be great if @marcofranssen was willing to help out too ❤️ I know he was also interested in pushing this forward
Second, where to host it .. from what I can tell, helm charts usually have their own repository, and are canonically discovered through ArtifactHUB .. is that correct? Are there other ways by which they may be published or discovered?
Third, we'll need some kind of integration testing I think .. I'm not sure what that normally looks like for Helm charts, but perhaps we can cargo cult some of the integration testing we already do in SPIRE if need be
And finally, we'll need some folks to help us maintain it 🤗
So I think that for us to get an "official" SPIRE helm chart published, we need:
- A new GitHub repository in the SPIFFE organization
- Helm chart itself, with documentation and examples
- GitHub Actions based integration tests that run nightly and on PRs
- Two maintainers
Does this sound right? How do folks normally name Helm repos? Is there typically one chart per repo, or many charts per repo?
Happy New Year @evan2645 and good to hear this is something Spire is interested in. With the chart I linked to, you can pull it directly from the GitHub release with (yes, that readme is missing all the documentation, quick PoC while we make progress on some other stuff):
helm repo add sudo-bmitch https://sudo-bmitch.github.io/helm-charts
helm repo update
helm upgrade --install spire sudo-bmitch/spire --values your-values.yaml --namespace spire --wait
For releasing with GitHub, I'm using the helm/chart-releaser-action here: https://github.com/sudo-bmitch/helm-charts/blob/main/.github/workflows/release.yml following their howto. ArtifactHub makes a lot of sense, and I've also been seeing discussions to get OCI artifacts out of experimental between Helm and ORAS, possibly in their next release, which allows you to host them in the registry along side your container images.
For testing, there's another GHA: helm/chart-testing-action. They're running it with Kind, and doing an install. Guessing we'd want to do some additional tests beyond just the install to make sure it's working, and I haven't tried Spire with Kind to know if there are any issues to work through.
For organizing the repos, the helm/chart-releaser-action I believe assumes you can have multiple charts, each in a separate folder within your charts repo. That lets you have an org/chart layout for users.
Happy to assist any way I can with this, including if you need an extra set of eyes on the maintainers team.
@sudo-bmitch looks like you took same approach as we did in https://artifacthub.io/packages/helm/philips-labs/spire.
I'm happy to migrate all commits related to spire into a new repository that can claim ownership by the spire core team. Our chart also does some level of integration testing with Kind, but definitely can use more.
I also had some thoughts on splitting the spire-agent and spire-server as separate charts with a toplevel chart to install both in one go.
@evan2645 Maybe you could create a spiffe/helm-charts repo. I will push my code there to get things started.
We have several Helm charts available for setting up SPIRE and Tornjak Server, as well as SPIRE agents, including steps for multi-cloud deployments. They support OpenShift, Kind, Minikube and deployments on some of the major cloud providers.
The charts are publicly available here: https://github.com/IBM/trusted-service-identity/blob/main/docs/README.md We would be happy to adapt them to general use and contribute them here as well.
Should we get a meeting going at some point to discuss how to move this forward?
Sorry folks, it took a while to get back to this. I put a doc here about the SPIRE Helm Chart proposal. Let's comment/edit it together and set on something. cc: @dfeldman
Awesome. I think the biggest issue is to have at least two committed maintainers. So far, I've seen @kfox1111 committed to doing so, and @dfeldman mentioned he could help as well. I tried to build a doc (link above) to summarize ideas and propose direction because we seem to want to put everything into the helm chart, which will make it hard to use and support (and some things won't be possible through it). As I mentioned in the doc, I feel this is a first step in the right direction to have something that brings easy experience to have SPIRE in the k8s cluster, but the right approach (long-term) should be developing the SPIRE operator and CLI for it.
IMO, operators are very useful when they add awareness of how the software needs to be operated to lifecycle properly. But are kind of a black box too. So should be used when there is a reason to need that special lifecycle. If the software can operate properly with just helm, its preferable to me to use helm in that case then add an operator just to have one. Do we think there are particular features of spire that would benefit from an operator?
There is already a spire-controller-manager that manages federation and workload registration. More things need to be implemented (e.g., CSI driver, datastore credentials management and rotation, and many other things that currently require restarting the SPIRE server).
spire-controller-manager & csi driver wouldn't need to manage lifecycle I think They are pretty straight forward functional wise.
Data store credentials should work with helm too I think. Rotation, maybe not? so that might benefit from an operator. Though, you may want those creds to be in ci/cd so maybe not?
Anything else we can think of?
I've done a couple ansible based operators and they weren't very difficult to get off the ground. But definitely more work then helm when not needed.
spire-controller-manager & csi driver wouldn't need to manage lifecycle I think They are pretty straight forward functional wise.
I brought the spire-controller-manager as an example of the work that is already done. You don't need to manage its lifecycle. It is quite the opposite - it manages the lifecycle of the SPIRE server. I suggest extending it to manage other areas that currently require a restart of the SPIRE server. Datastore credential management is just one example.
I am definitely interested in contributing to helm charts, especially in context of standing up SPIRE with a Tornjak instance. We currently have several helm charts for starting SPIRE Server with Tornjak on several platforms, as well as SPIRE agents for various installs across multi-cloud deployments with workload registrar and custom identity schemas.
It'd be better to link the Google doc started for the SPIRE Helm chart proposal here, thanks to @elinesterov 👏 Slack Announcement: https://spiffe.slack.com/archives/C7XDP01HB/p1664923493369869
I'm still willing to donate our chart to any repo of choice including commit history etc. for the sake of documentation etc. Also willing to co-maintain the helm-chart. Our chart is mainly focussed on plain kubernetes, but can be extended for all kind a specific distros.
Give me a repo, and magic will happen 🚀
I was hoping we could spend some time at the next sig spire meeting to demo the available solutions. What do you think?
When is the next Sig Spire meeting?
This thursday at 10:30 am pacific. Are you available? https://github.com/spiffe/spiffe/blob/main/community/sig-spire/README.md
I think the best path forward here is going to be to rally around a shared set of goals. I've read through the google doc, and I think it is a great start at this. Only after we agree on the shared set of goals/non-goals can we be in a position to decide which implementation is closest, and carry it forward.
IMO, the scope and philosophy behind the goals/non-goals currently captured in the doc are likely to be the bits requiring the most conversation ... my vote would be to have a dedicated 60 minute call where we discuss that part, and get some consensus... at which point, we can make an educated decision on how to move forward implementation-wise. Otherwise, we run the risk of jockeying for various (divergent) implementations without a clear picture on why we would choose one over the other.
Agree. Let's have a 60 min meeting next week with all people who want to participate, and we'll agree on the path forward and who can maintain the project moving forward. How about Thursday, November 17th, 9:30-10:30 am PT?
That sounds great, count me in. Sorry I couldn't be at contributors meeting today, but I also digested the Google doc and have a prototype helm chart that I'll cleanup and hopefully have as a starting point for discussion by that Thursday.
Agree. Let's have a 60 min meeting next week with all people who want to participate, and we'll agree on the path forward and who can maintain the project moving forward. How about Thursday, November 17th, 9:30-10:30 am PT?
Works for me.
Agree. Let's have a 60 min meeting next week with all people who want to participate, and we'll agree on the path forward and who can maintain the project moving forward. How about Thursday, November 17th, 9:30-10:30 am PT?
Should we use the same Zoom call as the standard SIG-SPIRE meetings?
Not sure if I can make it this Thursday. That means for me 18:30 PM CET.
@marcofranssen Whats your available hours/days to meet?
Reached out to you on Spire slack.
Created a #helm-charts channel on Slack so we can communicate about this a little more easily. If you need slack access you can register at slack.spiffe.io.
Hey folks, the meeting is scheduled for Wednesday, November 30th. Here is a link https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=MGYxNDBzNmg5M3AxZDlkOWE4bGkzdXYybmggZWxpLm5lc3Rlcm92QG0&tmsrc=eli.nesterov%40gmail.com I don't have email for @djcrabhat
Set up a bi weekly meeting for this starting Tuesday Jan 24 at 8:00 am US/Pacific. The info is in the SIG-SPIRE calendar.
Happy to see some progress being made on a decision to do this. When things look a bit more developed, I can certainly contribute to this as operators (which can be installed via Helm anyways) and standard Helm Charts are pretty much the defacto way of installing and managing deployments of applications/infrastructure on Kubernetes nowadays. Additionally, with the combination of GitOps agents like Flux, this makes things a lot easier.
