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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status of the project and where it's going #165

Open
kaspernissen opened this issue May 8, 2019 · 35 comments
Open

Status of the project and where it's going #165

kaspernissen opened this issue May 8, 2019 · 35 comments

Comments

@kaspernissen
Copy link

@kaspernissen kaspernissen commented May 8, 2019

We (lunarway) are very interested in this project and would like to discuss its current state and progress.

It seems that there are some great ideas, and solutions in PR's to bring this project to the next level. Unfortunately, the momentum seems to have slowed down, and there hasn't been an official release in over a year. We know it can be time consuming running an open-source project by yourself, as it's presented in the quote from @anguslees from an earlier issue and would, therefore, like to discuss options for collaboration to get this project moving again.

sealed-secrets is not a commercial product for Bitnami, so it gets time from me when I find gaps around other priorities. I wish it were otherwise, but that's the reality at present.

Originally posted by @anguslees in #106 (comment)

Possible solutions:

  • Open up for external contributors to help with PR's and issues
  • Find someone (a company) willing to take on the ownership of the project
  • Something else?

It would be very helpful to get an understanding of where this project is going. At least, it would be great to know how we can help as many in the community are either using this project or needs a solution like this in their kubernetes clusters.

@olliebun
Copy link

@olliebun olliebun commented May 14, 2019

Thanks for opening this discussion, @kaspernissen.

We (greensync) are excited about Sealed Secrets too, and we're in the process of rolling it out internally. It solves some problems we have better than anything else we could find in the Kubernetes space, and the code base is small and simple enough for us to understand and work on.

At the moment we're using our own fork of the CLI tool which cleans up the UX a little; there has been some discussion of this work, and some positive feedback, but we're not sure how to push it forward.

We are willing to invest and commit some development time to Sealed Secrets, and I think we have the right mix of use case and Go experience to contribute meaningfully. We aren't particularly fussed about how this gets done, as long as we can be confident that the project can be maintained. Our own fork is possible, but it'd be a shame to go down that road when there's some real community interest in this as an open-source project.

@kaspernissen
Copy link
Author

@kaspernissen kaspernissen commented May 16, 2019

We are in a very similar situation. We are also rolling sealed-secrets out internally at the moment. We have made some workarounds for the limitations of the current implementation and was thinking of forking and invest some in our own fork. However, as @ceralena mentions, that would be a shame to go down that path, when there's real community interest. The UX clean up by @ceralena looks very promising and useful, and would love to see this merged.

Maybe yesterdays acquisition of bitnami could help get this project kickstarted?

@cknowles
Copy link

@cknowles cknowles commented May 17, 2019

Just chipping in another view as I have been a contributor to this project as have some of my previous colleagues. I am not a user of this project at the moment so harder to spend the time on it but willing to contribute if others take ownership.

Historically myself and previous colleagues found it a bit difficult to get changes in so it’d be good if more people have access to help with PRs and issues. Not sure if there would be any blockers to that, presumably there wouldn’t be if it’s not a commercial product.

@anguslees
Copy link
Contributor

@anguslees anguslees commented May 23, 2019

Thanks for starting this discussion @kaspernissen. Yes, I think we can all see that we need to find a way for sealed-secrets not to have me/Bitnami in the critical path ;)

Just so everyone knows, part of the issue preventing new releases atm is a boring semi-technical one:

  • We changed the SealedSecrets schema in #88 to add the Secret type field.
  • I wanted to change the schema again to add a more generic template in #129
  • I wanted to avoid all the stable-release users going through two consecutive schema migrations, so wanted to merge #129 before tagging a release that included #88.
  • I never finished #129 (and worse, I said I would, which probably discouraged other people from working on the related issues)

Because of this blockage, we haven't made any new releases since before #88, which is now a long time ago. In hindsight it would have been better just to release with the intervening schema, but of course I always intended to complete #129 in a timely fashion.


At this point, I'm going to openly do whatever I can to get out of the way: what do people want to do here?

I think we need:

  • at least one new shepherd for the project.
    This needs to be someone who is mostly-comfortable with the security/crypto aspects, since there are occasional PRs/suggestions that need to be rejected or else they would take the project in a direction that involves a different and conflicting security model (ie: it isn't just about merging every contribution unfortunately).
  • to unblock the release pipeline.
    This is mostly just a matter of actually tagging releases again.

This may or may not involve renaming the git repo away from bitnami-labs/ (but there is no need to do this just to have other people involved. I can add external admins to the existing github project). We could even move it into its own sealed-secrets/sealed-secrets github org if we wanted to have a stable future-proof home. A git rename involves trivially renaming all the golang imports (because golang), and optionally/less-trivially renaming the k8s apiGroup, I will support whatever people want to do here.

I still use this project everyday personally, and continue to care about it. So I am happy to (and would like to) continue to be involved - assuming that's ok with the new shepherds. We just need to find a way for me to transition to a "supporting" rather than "gatekeeper" role.

@anguslees
Copy link
Contributor

@anguslees anguslees commented May 23, 2019

Oh, and a massive ❤️ to everyone who has contributed, in any capacity. @c-knowles deserves a particular mention for sustained code + user support contributions early in the project :)

@demisx
Copy link

@demisx demisx commented May 24, 2019

After researching many offerings, I’d say this is indeed the best straightforward solution in Kubernetes world so far and would be awful not to see it getting its pulse back. Thank you @anguslees and the rest of the team for all your great work. We’ll be watching.

@kaspernissen
Copy link
Author

@kaspernissen kaspernissen commented May 28, 2019

Thank you for the detailed description and openness, @anguslees! It is highly appreciated and thank you very much for a great project.

Creating a separate org sealed-secrets/sealed-secrets sounds like a good idea. That would as you mention, create a future-proof home.

As mentioned in the initial post, we would love to help out, both @Crevil and myself. However, neither of us probably don't have the security/crypto skills needed to become shepherds for a project like this, but we could help out in other areas and assist as much as possible.

@yob
Copy link

@yob yob commented Jun 5, 2019

I work with @ceralena and wanted to chime in.

It seems like there's a number of people willing to chip in on development, and some uncertainty about the best way to co-ordinate going forward. In the short term, I wonder if we can optimise for unblocking the release train for:

  1. bug fixes
  2. modest functional changes that @anguslees feels are aligned with the sealed-secrets vision

@anguslees, would you be open to something like this:

  1. Identifying (or creating) a few issues that describe the non-radical changes you'd like to see in the short term ( the template schema change, using kube events for debugging, etc)
  2. Adding a few extra committers
  3. Requesting that all committers contributions go via PR (for visibility)
  4. Asking that all PRs have a review from a second committer before being merged, and are either a bugfix or resolving an issue from (1)

Hopefully that will allow some of us to pickup development of the blocking work.

If we can get a few small and successful releases out, we'll be more familiar with eachother and may be in a better position to decide on an alternative collaborative style that is more sustainable long term

@chrisharm
Copy link
Contributor

@chrisharm chrisharm commented Jun 14, 2019

Hi all,
Thanks for starting this conversation. My team is actively using the sealed-secrets project too, and we see the value in it's continued support. I am also willing to contribute to the project, but don't know the best way to move forward. @yob I like many of your suggestions.

I spent some time over the last two days trying to get familiar with the code base, and @anguslees changes in #129. I have attempted to finish this effort and have submitted #170. All of the integration test now pass locally, and I merged the other changes from master into my branch. I'll offer this up as a test to see if we can continue to move the project forward.

@anguslees How would you like to open up the project for new contributions? Who currently has access?

Thanks,
Chris

@monadic
Copy link

@monadic monadic commented Jun 16, 2019

@anguslees @kaspernissen we would love to shepherd this project, ideally long term towards the CNCF in some way shape or form. Perhaps we could all work on this together? Please let me know! Alexis @ Weaveworks.

@kaspernissen
Copy link
Author

@kaspernissen kaspernissen commented Jun 17, 2019

It sure sounds like there's a great interest in forming a new working group around this project. Thank you for pitching in @monadic. I think Weaveworks would be good shepherds as you have experience running open source projects, and this project fits right in the GitOps philosophy that you are promoting.

Agree with @yob we need to figure out what the next step is - and how we can start contributing to unblock the release train. Can we form a working group and discuss the next steps in a call?

Great work @chrisharm! This is a great step forward.

@anguslees how would you like to proceed?

@olliebun
Copy link

@olliebun olliebun commented Jun 18, 2019

I just saw this comment from @mkmik:

#143 (comment)

Sorry for the delay, bitnami went through an acquisition and we scrambled a bit.
The original maintainer left the company; I'm going to fill that role.

Let me see if this branch is still clean and fully understand out the backward compat implications.

@mkmik - Hi there! Just wanting to make sure you're aware of this conversation.

@victornoel
Copy link

@victornoel victornoel commented Jun 26, 2019

So, anything new on this? Has there been some working group spawned a @kaspernissen was proposing? @mkmik?

@kaspernissen
Copy link
Author

@kaspernissen kaspernissen commented Jun 26, 2019

Unfortunately not, we have been trying to reach out via e-mail as well. @monadic is trying to pull some strings in his network, to see if we can get a response.

@mariusmarais
Copy link

@mariusmarais mariusmarais commented Jun 27, 2019

I realise this is bad style on my part, but I'm moving on to https://github.com/Soluto/kamus

It might be time to cut our losses and start looking at alternatives.

@glerchundi
Copy link

@glerchundi glerchundi commented Jun 27, 2019

We're also interested in keeping this active and open to collaborate.

Now that It's been over a month since the former maintainer said something (👋 @anguslees) and the new one seems to be missing too (👋 @mkmik), perhaps it's time to think on a deadline to push this forward by creating a fork under a new organisation. WDYT?

In case this makes sense, a deadline for after holidays and before winter ones seems to be something reasonable to let current maintainers have enough time to self pronounce.

Although I think this should be last option.

@lopezator
Copy link

@lopezator lopezator commented Jun 27, 2019

It seems that there is a lot of interested people on moving this forward, but it doesn't look this is moving anywhere (more than one month since the thread start).

Maybe time to start a fork?

@mkmik
Copy link
Collaborator

@mkmik mkmik commented Jun 27, 2019

Hi. I've been traveling and now I'm back. Sorry for the chaos, acquisitions can disrupt your flow.
I will resume active maintenance.

In the meantime we can talk about how to move forward to a more manageable model.

@kaspernissen
Copy link
Author

@kaspernissen kaspernissen commented Jun 28, 2019

@mkmik great to hear. What do you think of adding more contributors to be able to build up a momentum for this project again? And how can we help to get the project back on track, and get on a steady release cycle again?

Do you want to keep this project under the bitnami-labs org, or perhaps move it to it's own?

@mkmik
Copy link
Collaborator

@mkmik mkmik commented Jun 28, 2019

@kaspernissen, I organised a small team here (this is no longer a one-man show of a small startup); I'd prefer to first go through the backlog and unblock the release cycle again and then we can reason about long term governance.

I'm really excited about the interest this project has generated and I'm committed to facilitate the community to come up with improvements and solutions to real-world problems we all have.

@chrisharm
Copy link
Contributor

@chrisharm chrisharm commented Jul 1, 2019

Let us know if there is anything that we can do to help.

@zachaller
Copy link

@zachaller zachaller commented Jul 18, 2019

I see there has been a lot of work happening in the project again, thanks for all the work! I am wondering if there is any rough estimate or timeline for a .8 release really looking forward to template support and the ability of being able use different types. It's a bit of a blocker on our current rollout of kubeseal.

@kbirger
Copy link

@kbirger kbirger commented Jul 19, 2019

I think there is a separate discussion on this one point, but since we are talking about regaining momentum, I think it's worth mentioning that a huge impediment for several people is the lack of an official windows distribution.

Yes, lots of people use Windows, and a lot of them work in the k8s space. There is an ad-hoc binary floating around this issue tracker, but it's not the same as an official build.

@mkmik
Copy link
Collaborator

@mkmik mkmik commented Jul 19, 2019

@kbirger makes sense (tracked in #85)!
I will include a windows build in the v0.8.0 (coming very soon)

@mkmik
Copy link
Collaborator

@mkmik mkmik commented Jul 19, 2019

v0.8.0-rc.1 released.
Early testers appreciated.

@kbirger
Copy link

@kbirger kbirger commented Jul 19, 2019

Awesome. I'll give this a shot in our QA environment on Monday. Not sure if I have any use cases for the new features, but I'll do what I can.

Have a great weekend and thanks for the hard work.

@zachaller
Copy link

@zachaller zachaller commented Jul 20, 2019

It seems like the tag in the yaml is missing from quay.io but the latest tag seems to have been updated might want to push a tag that matches the yaml. Again super excited for this release thanks for all the work!

@glerchundi
Copy link

@glerchundi glerchundi commented Jul 20, 2019

@mkmik
Copy link
Collaborator

@mkmik mkmik commented Jul 22, 2019

@zachaller
Copy link

@zachaller zachaller commented Jul 22, 2019

@mkmik thanks!! I see it now and its been working great so far.

@olliebun
Copy link

@olliebun olliebun commented Jul 23, 2019

Just wanted to drop in and highlight how great it is to see so much movement on this project. I'm sure it's a relief to many. @mkmik thank you for your pragmatic approach!

@nrvnrvn
Copy link

@nrvnrvn nrvnrvn commented Aug 7, 2019

Hey everyone!

I am excited to introduce a new operator and CLI for managing and encrypting secrets: https://github.com/amaizfinance/secreter

Actually I had been considering using Sealed-secrets but after careful review of the features (as of early 2019) and issues it became clear that it is better to write a new one from scratch. This particular issue is one of the major issues why we decided to start from scratch instead of trying to contribute to this project. @mkmik thanks a lot for finally moving this project forward and all the work you are doing for the Sealed Secrets.

Please read through the Readme to learn about the features, overview of cryptography and security, give it a try and provide any feedback - the more the better. If I am not mistaken most of the open feature requests for Sealed Secrets are already implemented in Secreter.

We are currently evaluating secreter in our test and sandbox environments. I am going to take care of gcpkms integration shortly in order to be able to move to more production grade testing.

Ideally I would like Secreter to eventually become a CNCF project. The main reason for this is that I believe that handing over such a project to the community is a huge security benefit.

I thought it would be a good idea to put a notice here because most of the people caring about client side Kuberenetes secrets encryption are already here.

Thank you!

@mkmik
Copy link
Collaborator

@mkmik mkmik commented Aug 7, 2019

This particular issue is one of the major issues why we decided to start from scratch instead of trying to contribute to this project.

Well, if this issue was the only problem you had the option to fork the project ;-) Creating one from scratch is also an option. I assume this means sealed-secrets internal design doesn't suite you well enough. If you believe that's the fastest way to solve your problems, feel free to pursue it.

I believe that handing over such a project to the community is a huge security benefit.

I also share that belief; I just wanted to actually fix blocker issues before engaging with bureaucracy.

@jaygorrell
Copy link

@jaygorrell jaygorrell commented Aug 7, 2019

I do like the idea of an operator (oops, blanked out on that one), but I feel like announcing a new project here after this is no longer inactive is a bit in bad taste.

@mkmik
Copy link
Collaborator

@mkmik mkmik commented Aug 7, 2019

@jaygorrell fwiw sealed-secrets is an operator too

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

Successfully merging a pull request may close this issue.

None yet