# Kubernetes External Secrets > [TOC] ## Meeting Notes TLDR; * we'll use this org: http://github.com/external-secrets and move `godaddy/kes` there. * meanwhile we'll create a new controller based on the CRD spec * we'll have bi-weekly meetings and use slack for async communication We'll create a new project (in that org) from scratch instead of moving the projects from `itscontained` or `containersolutions`. We'll copy-paste from these projects and try to attribute the commits to the original authors. Because some contributors use company time to develop OSS we agreed on putting a company logo or link into the Readme. ### Action Items * @silas ask internal open source board to transfer ownership * check MIT -> Apache license transition * @Markus add us to organization * knelasevero * moolen * jonatasbaldin * iamcaleberic * mircea-cosbuc * amouat * silasbw * mcavoyk * @Jonatas: create empty project / scaffold basic structure * create new repo * migrate "godaddy one" (now the "community one") * create empty branch * push new repo/branch to the community one * @moolen * create reminder for bi-weekly meeting ## Community Meeting #1 Hello everyone! Let's have a community meeting to discuss future plans around the `kubernetes-external-secrets` project. This document is the the agenda for our first meeting. Everyone is allowed to comment, ping me if you need write access. Feel free to add more topics to this document! ## Goal I'd like to have a discussion about possible next steps for our effort to consolidate the different `external-secret` projects. ## TODOs / decisions to make - [ ] pick GitHub organization (`external-secrets` owned by @Flydiverny? we probably want GitHub premium for faster CI) - [ ] decide which project/code to use as basis - [ ] merge/close CRD spec? https://github.com/godaddy/kubernetes-external-secrets/pull/477 ## Topics to discuss ### Long-Term plan * apply for CNCF sandbox?! (see [process](https://github.com/cncf/toc/blob/master/process/sandbox.md)) * host the project in a Kubernetes SIG?! (e.g. [sec-profile-operator](https://github.com/kubernetes-sigs/security-profiles-operator) is similar in context) ### Project Governance I'd like to propose something similar to [containerd governance document](https://github.com/containerd/project/blob/master/GOVERNANCE.md). Topics to discuss: * Licensing: Apache vs. AGPL vs. ...? * Contribution Policy * Maintainership Policy * Decision Making Process * Communication: schedule regular meetings / office hours?! * proposal: monthly scheduled meeting to bring up important issues, pull requests. announced via k8s-slack channel * Community Support Channels * what support channels do we want to maintain? * GH issues for well-documented issues and feature requests * k8s-slack to help with quick questions * is stackoverflow relevant? * OSS Marketing Roadmap * is someone here with experience that can give us direction? * regular posts on `/r/golang` and `/r/kubernetes` * (online-)meetups, conferences, blogs & magazines * anything else? ### Migration Plan * we want a GitHub organization to host the new project to have a "$company neutral ground" aswell as haveing maintainers from different $COMPANIES * there are several projects out there, which one should we pick as a foundation? One of the following projects may suit as a foundation for our joint-venture: * https://github.com/itscontained/secret-manager * https://github.com/ContainerSolutions/externalsecret-operator * please add more * -> how do we choose a project? flip a coin? * -> when and how can we start with development? * what do we do with the ~~old~~ current codebase? * maintenance mode? how to proceed with open PRs and issues? * how do we integrate the new codebase? * use a `v2` branch without history? ### Technical Project Milestones This is a rough braindump. We should probably have another session to extend the roadmap. The phases are similar to [sig-architecture/api-changes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md#alpha-beta-and-stable-versions). #### pre-alpha (development) This is the initial phase used for the implementation of basic features and experimentation. This will change drasticially. DO NOT RUN THIS IN PRODUCTION. * project inception (the migrated codebase) * integrate major external secret provider (TBD) * implement CRD Spec * basic documentation, examples * basic observability metrics #### alpha (experimental) This is a stable*ish* phase to smoothen out rough edges. Things should not drasticially change but may do. Not all API operations, CLI flags may be implemented. It's not recommendend to run this in production. But you can if you use your brain and be cautious. * integrate all relevant external secret provider with e2e tests (TBD) * enhanced documentation with examples, including use-cases * define a process to bring this project to a beta level #### beta (pre-release) All API operations and CLI flags should be implemented. Semantics may change, if so the process will be documented. * documentation about usage scenarios and best practices * auditability & compliance metrics * gather feedback from users: UX & use-case analysis * ??? #### GA (stable) * ??? #### References I just wanted to create a list of projects that play on the same field: * https://github.com/godaddy/kubernetes-external-secrets * https://github.com/ContainerSolutions/externalsecret-operator * https://github.com/itscontained/secret-manager * https://github.com/mumoshu/aws-secret-operator * https://github.com/cmattoon/aws-ssm * https://github.com/contentful-labs/kube-secret-syncer * https://github.com/aws-samples/aws-secret-sidecar-injector * https://aws.amazon.com/ko/blogs/containers/aws-secrets-controller-poc/ * https://github.com/kubernetes-sigs/secrets-store-csi-driver This problem is a big issue in the EKS/AWS-Containers roadmap (see [aws/containers-roadmap#168](https://github.com/aws/containers-roadmap/issues/168))