**Description** <!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. --> Although Kubernetes-reflector can be used to mirror both generic Configmaps and Secrets across k8s namespaces, with this PR I specifically intend to lay the groundwork for supporting wildcard certificates in Truecharts. To keep things small this PR only adds the app needed to support secrets mirroring across namespaces. The rest of the functionality will be added through separate PRs. A high-level overview of how I picture this to work: - A user will gain the ability to create "cluster-wide" certificates in the `clusterIssuer` app config. This will generate the certificates and store them in the app's namespace - The created/updated certificates will be mirrored automatically to all namespaces matching the regex `ix-.+` (or configurable for helm users) with the help of the `kubernetes-reflector` app - The user will gain the ability to use a "cluster-wide" certificate when setting up an ingress for an app. Similar to how they can currently use a custom secret for an ingress cert. To achieve this in next PRs I will be: - Submitting small patches to the common lib. So far I think the only change needed is to allow setting annotations to `Certificate` CRDs, which is needed to allow `kubernetes-reflector` to replicate them (see [cert-manager docs](https://cert-manager.io/docs/devops-tips/syncing-secrets-across-namespaces/#using-reflector)) - Submitting small patches to the clusterIssuer app and the `Ingress{*}.yaml` files Relevant issue: #8634 I have not yet added the image to the TC repo. Will do that after the review process, before merging. ⚒️ Fixes # <!--(issue)--> **⚙️ Type of change** - [X] ⚙️ Feature/App addition - [ ] 🪛 Bugfix - [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to not work as expected) - [ ] 🔃 Refactor of current code **🧪 How Has This Been Tested?** <!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration --> I have tested this by deploying the `kubernetes-reflector` app and then applying the following yaml: ```yaml apiVersion: v1 kind: Namespace metadata: name: origin --- apiVersion: v1 kind: Namespace metadata: name: destination1 --- apiVersion: v1 kind: Namespace metadata: name: destination2 --- apiVersion: v1 kind: Namespace metadata: name: another-destination1 --- apiVersion: v1 kind: Namespace metadata: name: another-destination2 --- apiVersion: v1 kind: Secret metadata: annotations: # Allow reflection from source namespaces reflector.v1.k8s.emberstack.com/reflection-allowed: "true" # Namespaces from/to which reflection is allowed reflector.v1.k8s.emberstack.com/reflection-allowed-namespaces: "origin,(another-)?destination\\d+" # Auto reflect secrets/configmaps to destination namespaces reflector.v1.k8s.emberstack.com/reflection-auto-enabled: "true" # Destination namespaces reflector.v1.k8s.emberstack.com/reflection-auto-namespaces: "(another-)?destination\\d+" name: my-secret namespace: origin type: Opaque data: mydata: c2VjcmV0Cg== # mydata: c3VwZXJzdXBlcnNlY3JldAo= ``` Exact commands and output: ```bash $ kubectl create ns ix-kubernetes-reflector $ helm install -n ix-kubernetes-reflector kubernetes-reflector . $ kubectl get secrets --all-namespaces NAMESPACE NAME TYPE DATA AGE kube-system pop-os.node-password.k3s Opaque 1 144d kube-system k3s-serving kubernetes.io/tls 2 144d ix-kubernetes-reflector sh.helm.release.v1.kubernetes-reflector.v1 helm.sh/release.v1 1 8s $ kubectl apply -f test-reflect.yaml namespace/origin created namespace/destination1 created namespace/destination2 created namespace/another-destination1 created namespace/another-destination2 created secret/my-secret created $ kubectl get secrets --all-namespaces NAMESPACE NAME TYPE DATA AGE kube-system pop-os.node-password.k3s Opaque 1 144d kube-system k3s-serving kubernetes.io/tls 2 144d ix-kubernetes-reflector sh.helm.release.v1.kubernetes-reflector.v1 helm.sh/release.v1 1 29s origin my-secret Opaque 1 5s destination1 my-secret Opaque 1 5s destination2 my-secret Opaque 1 5s another-destination1 my-secret Opaque 1 5s another-destination2 my-secret Opaque 1 5s $ kubectl describe secret -n destination1 my-secret | tail -1 mydata: 7 bytes $ # Change the secret value (uncomment the other key and comment the first one) $ kubectl apply -f test-reflect.yaml $ kubectl describe secret -n destination1 my-secret | tail -1 mydata: 17 bytes $ kubectl delete secret -n origin my-secret secret "my-secret" deleted $ kubectl get secrets --all-namespaces NAMESPACE NAME TYPE DATA AGE kube-system pop-os.node-password.k3s Opaque 1 144d kube-system k3s-serving kubernetes.io/tls 2 144d ix-kubernetes-reflector sh.helm.release.v1.kubernetes-reflector.v1 helm.sh/release.v1 1 3m24s ``` **📃 Notes:** <!-- Please enter any other relevant information here --> **✔️ Checklist:** - [X] ⚖️ My code follows the style guidelines of this project - [X] 👀 I have performed a self-review of my own code - [X] #️⃣ I have commented my code, particularly in hard-to-understand areas - [ ] 📄 I have made corresponding changes to the documentation - [X] ⚠️ My changes generate no new warnings - [X] 🧪 I have added tests to this description that prove my fix is effective or that my feature works - [X] ⬆️ I increased versions for any altered app according to semantic versioning **➕ App addition** If this PR is an app addition please make sure you have done the following. - [ ] 🪞 I have opened a PR on [truecharts/containers](https://github.com/truecharts/containers) adding the container to TrueCharts mirror repo. - [X] 🖼️ I have added an icon in the Chart's root directory called `icon.png` --- _Please don't blindly check all the boxes. Read them and only check those that apply. Those checkboxes are there for the reviewer to see what is this all about and the status of this PR with a quick glance._ --------- Signed-off-by: sdimovv <36302090+sdimovv@users.noreply.github.com> Signed-off-by: Kjeld Schouten <kjeld@schouten-lebbing.nl> Co-authored-by: Stavros Kois <47820033+stavros-k@users.noreply.github.com> Co-authored-by: Kjeld Schouten <kjeld@schouten-lebbing.nl>
TrueCharts
Community Chart Catalog for TrueNAS SCALE
TrueCharts is a catalog of highly optimised TrueNAS SCALE Charts. Made for the community, By the community!
Our primary goals are:
-
Micro-Service Centered
-
Native Kubernetes
-
Stability
-
Consistency
All our charts are supposed to work together, be easy to setup using the TrueNAS UI and, above all, give the average user more than enough options to tune things to their liking.
Getting started using TrueCharts
Installing TrueCharts within TrueNAS SCALE, is possible using the TrueNAS SCALE Catalog list.
Check TrueCharts Quick-Start Guides for more information.
Support
Please check our FAQ, manual and Issue tracker There is a significant chance your issue has been reported before!
Still something not working as expected? Contact us! and we'll figure it out together!
Roadmap
For big changes we do have a roadmap, every spot on the roadmap is synced to a TrueNAS SCALE Release and should be read as "Should be added at or before this release"
Restructure of the Project - TrueNAS SCALE "Bluefin" 22.xx ALPHA 1
The current project is hitting internal performance issues, for this reason we need to rework the structure and split some parts of the project into separate repositories.
Refactor the Common Chart - TrueNAS SCALE "Bluefin" 22.xx ALPHA 2
The shared Common (chart) basis, used by all our Charts, needs some significant code cleanup. Primarily all code needs to follow a standardised format and comply to the same standard
Increased test coverage - TrueNAS SCALE "Bluefin" 22.xx BETA 1
With most parts of our project somewhat cleaned up, we need to work on increasing the coverage of our test system. Our unit tests should cover all features and we should also take upgrades into account when testing Chart changes
Development
Our development process is fully distributed and agile, so every chart-maintainer is free to set their own roadmap and development speed and does not have to comply to a centralised roadmap. This ensures freedom and flexibility for everyone involved and makes sure you, the end user, always has the latest and greatest of every Chart installed.
Getting into creating Charts
Creating charts takes some getting used to, as it's based on Helm charts. We highly suggest prior know-how on creation/modifying Helm Charts, before taking on the challenge of creating SCALE Apps.
For more information on creating SCALE Apps and Helm charts, please check out our development manual
Automation and you
We provide a lot of tools to make it easier to develop charts, templates, automated testing, automated fixes, automated docs. Even automated update is included. We also actively try to collaborate with other k8s community projects on tooling, for the betterment of all!
Those tools do, however, take time to develop and are certainly not bug free. If you find mistakes in our tooling, please feel free to repost issues or submit any fixes you feel appropriate!
Contact and Support
To contact the TrueCharts project:
-
Create an issue on Github issues
-
Open a Support Ticket
-
Send us an email
Featured Projects
A lot of our work is based on the great effort of others. We would love to extend special thanks to these projects we owe a lot to:
|
|
|
|
|---|---|---|---|
| TrueNAS SCALE | K8S-At-Home | Traefik | Authelia |
Contributors ✨
Thanks goes to these wonderful people (emoji key):
This project follows the all-contributors specification. Contributions of any kind welcome!
Licence
Truecharts, is primarily based on a BSD-3-clause license, this ensures almost everyone can use and modify our charts. As a lot of Charts are based on upstream Helm Charts, Licences can vary on a per-Chart basis. This can easily be seen by the presence of a "LICENSE" file in said folder.
An exception to this, has been made for every document inside folders labeled as docs or doc and their subfolders: those folders are not licensed under BSD-3-clause and are considered "all rights reserved". Said content can be modified and changes submitted per PR, in accordance to the github End User License Agreement.
SPDX-License-Identifier: BSD-3-Clause