Ayush KumarandGitHub
7a4e59b295
* Merge commit from fork * fix: prevent unbounded read in Terraform remote configuration loader (GHSA-fmgp-q6jx-gg3x) * fix: bound remote Terraform clone and invalidate cache on rejection Follow-up hardening for GHSA-fmgp-q6jx-gg3x. Bound the clone of the attacker-supplied repository: shallow Depth:1, a 2-minute fetch timeout via PlainCloneContext, and post-clone caps on the retained tree size (64 MiB) and file count, rejecting and removing a clone that exceeds them. Invalidate the clone cache: re-clone when the recorded remote URL changes, and remove the cache on a failed clone or a rejected read so a corrected repository is re-fetched instead of a poisoned or stale tree being reused. Validate the module name before building the cache path, and log clone, rejection, and eviction events. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Fix: resolve gosec G304 lint failure in Terraform module cache check (#7190) Wrap the cache remote marker read in filepath.Clean, the same pattern other os.ReadFile call sites in this repo use to satisfy gosec. The path is built from filepath.Join and a constant suffix, with the module name validated beforehand, so behavior is unchanged. The finding surfaced on master after the GHSA-fmgp-q6jx-gg3x merge because the advisory workflow did not run the full lint job. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Chore: bump actions/cache to v4 in CI workflows GitHub has closed down actions/cache v1 and v2. Any job pinned to the old SHA (704facf57e6136b1bc63b828d79edcd491f0ee84) is now automatically failed at job setup, before any step runs. On this branch that broke check-diff, check-windows, and unit-tests (each failing in a few seconds with no logs). Bump the three references in go.yml and unit-test.yml to actions/cache@v4, matching the version already used on master, so these jobs can run again. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Chore: install envtest binaries via setup-envtest in unit tests The RyanSiu1995/kubebuilder-action step fetched kube-apiserver and kubectl from the kubernetes-release and kubebuilder-tools storage buckets, which have since been retired. Those downloads now return small 404 error pages that get saved as the binaries, so envtest cannot start the control plane (exec format error) and the unit-test BeforeSuite panics. Replace that step with the official prebuilt setup-envtest, which pulls the matching envtest bundle (etcd, kube-apiserver, kubectl) for Kubernetes 1.26.1 from the current controller-runtime release index and exports its path through KUBEBUILDER_ASSETS. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Chore: pin cache action and harden envtest install per review Address automated review feedback on the CI changes: - Pin actions/cache to a commit SHA (v4.3.0, 0057852) in go.yml and unit-test.yml instead of the mutable v4 tag, matching how every other action in these workflows is pinned. - Add curl -f to the setup-envtest download so an HTTP error fails the step immediately instead of saving an error page as the binary. - Verify the downloaded setup-envtest against a known SHA-256 before running it. - Capture the envtest asset path into a variable and fail fast when it is empty or not a directory, rather than letting a failed command substitution slip through and surface later as a confusing make test error. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Fix: load 0.2.0 helm test chart from local file instead of dead repo The helm helper test fixture pointed version 0.2.0 at https://charts.kubevela.net/example/autoscalertrait-0.1.0.tgz, but that host no longer resolves. Once the unit-test suite could run again, "Test getValues from chart" failed with "cannot load chart from chart repo". Point the 0.2.0 entry at the local autoscalertrait-0.2.0.tgz that already ships in testdata, matching how master resolves this chart, so the test no longer depends on an external network endpoint. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Fix: point addon CLI tests at the live KubeVela registry The addon listing and status tests registered https://addons.kubevela.net, which no longer resolves, so the three "addon in the registry" cases failed once the suite could run again. Point them at https://kubevela.github.io/catalog/official, the registry that master already uses for these same tests. The only difference between this file and master was this URL (the assertions are identical), and that host still serves the addons the assertions expect. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Chore: re-trigger CI for stuck e2e jobs Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Fix: run release-1.9 e2e jobs on GitHub-hosted runners The e2e-tests and e2e-multi-cluster-tests jobs targeted self-hosted runners, which GitHub does not assign to pull requests from forks. The jobs sat queued until the 24h ceiling and were cancelled, so they never ran on this PR (the original run shows no runner assigned and zero steps executed). Switch both to ubuntu-22.04, the GitHub-hosted runner that release-1.10 and master already use for these jobs, where the same fork-based backport runs them successfully. These workflows are self-contained (they install their own tools and create the kind cluster inline), so no other change is needed. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Fix: wait for flux controllers before enabling the terraform e2e addon The e2e post-hook enabled the terraform addon right after fluxcd. The terraform addon's controller is a flux HelmRelease that needs the flux source-controller and helm-controller pods running to reconcile, but flux readiness was only checked after every addon had been enabled. On the GitHub-hosted runner (slower than the self-hosted one this hook was written for) the terraform addon enable timed out after 600s waiting on a reconcile that could not happen until flux was up. Add the flux-system readiness checks before the terraform addon enable so flux is reconciling before the addon that depends on it is applied. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Fix: enable terraform e2e addon with terraform-controller 0.8.0 The terraform addon enable timed out after 600s on the GitHub-hosted runner. A previous attempt that waited for the flux controllers to be Ready before enabling the addon did not help: the run logs confirm source-controller and helm-controller were Ready and the terraform addon still timed out, so flux readiness was not the cause. Revert that wait. The real difference from master, where this addon enables cleanly, is the terraform-controller chart: release-1.9 pinned 0.2.11 from charts.kubevela.net, while master uses 0.8.0 from kubevela.github.io/charts with the ghcr image. Backport that chart version and image override so the addon controller becomes healthy in time. Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> * Fix: do not log or persist credentials embedded in Terraform module remote URLs GetTerraformConfigurationFromRemote logged the raw remote URL and wrote it to the .remote-url cache marker. An authenticated Git URL such as https://user:token@host/repo.git embeds credentials in its userinfo, so the raw value leaked secrets into controller logs and onto disk. Strip any embedded userinfo with a new redactURLCredentials helper before the URL is logged or recorded, and compare against the stripped form when checking the cache marker so cache reuse still works. scp-style SSH URLs authenticate with keys and carry no secret, so they pass through unchanged. See GHSA-fmgp-q6jx-gg3x. Signed-off-by: Ayush Kumar <65535504+roguepikachu@users.noreply.github.com> * Fix: discover traits from a reachable registry in the e2e raw-url test The e2e registry test discovered traits from oss://registry.kubevela.net, whose TLS certificate expired in May 2025, so e2e-tests failed with a certificate verification error. The default-registry listing test hits the same expired endpoint. Match release-1.10: point raw-url discovery at the GitHub-hosted registry, and disable the default-registry listing until the default registry is updated. Signed-off-by: Ayush Kumar <65535504+roguepikachu@users.noreply.github.com> --------- Signed-off-by: Ayush Kumar <ayushshyamkumar888@gmail.com> Signed-off-by: Ayush Kumar <65535504+roguepikachu@users.noreply.github.com>
Make shipping applications more enjoyable.
Introduction
KubeVela is a modern application delivery platform that makes deploying and operating applications across today's hybrid, multi-cloud environments easier, faster and more reliable.
Highlights
KubeVela practices the "render, orchestrate, deploy" workflow with below highlighted values added to existing ecosystem:
Deployment as Code
Declare your deployment plan as workflow, run it automatically with any CI/CD or GitOps system, extend or re-program the workflow steps with CUE. No ad-hoc scripts, no dirty glue code, just deploy. The deployment workflow in KubeVela is powered by Open Application Model.
Built-in observability, multi-tenancy and security support
Choose from the wide range of LDAP integrations we provided out-of-box, enjoy enhanced multi-tenancy and multi-cluster authorization and authentication, pick and apply fine-grained RBAC modules and customize them as per your own supply chain requirements. All delivery process has fully automated observability dashboards.
Multi-cloud/hybrid-environments app delivery as first-class citizen
Natively supports multi-cluster/hybrid-cloud scenarios such as progressive rollout across test/staging/production environments, automatic canary, blue-green and continuous verification, rich placement strategy across clusters and clouds, along with automated cloud environments provision.
Lightweight but highly extensible architecture
Minimize your control plane deployment with only one pod and 0.5c1g resources to handle thousands of application delivery. Glue and orchestrate all your infrastructure capabilities as reusable modules with a highly extensible architecture and share the large growing community addons.
Getting Started
Documentation
Full documentation is available on the KubeVela website.
Blog
Official blog is available on KubeVela blog.
Community
We want your contributions and suggestions! One of the easiest ways to contribute is to participate in discussions on the Github Issues/Discussion, chat on IM or the bi-weekly community calls. For more information on the community engagement, developer and contributing guidelines and more, head over to the KubeVela community repo.
Contact Us
Reach out with any questions you may have and we'll make sure to answer them as soon as possible!
-
Slack: CNCF Slack kubevela channel (English)
-
DingTalk Group:
23310022(Chinese) -
Wechat Group (Chinese): Broker wechat to add you into the user group.
Community Call
Every two weeks we host a community call to showcase new features, review upcoming milestones, and engage in a Q&A. All are welcome!
- Bi-weekly Community Call:
- Bi-weekly Chinese Community Call:
Talks and Conferences
Check out KubeVela videos for these talks and conferences.
Contributing
Check out CONTRIBUTING to see how to develop with KubeVela.
Report Vulnerability
Security is a first priority thing for us at KubeVela. If you come across a related issue, please send email to security@mail.kubevela.io .
Code of Conduct
KubeVela adopts CNCF Code of Conduct.