check-spelling
cert-manager
check-spelling | cert-manager | |
---|---|---|
2 | 101 | |
241 | 11,486 | |
2.9% | 1.1% | |
7.8 | 9.8 | |
3 days ago | 4 days ago | |
Shell | Go | |
MIT License | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
check-spelling
-
Add check-spelling to a repository
View on GitHub
-
GitHub Actions checkspelling community workflow GitHub_TOKEN leakage via symlink
> If my repo always runs all tests on a PR, could someone just add a PR with a new test that is then run? Thus running their arbitrary code.
Running arbitrary code is inevitable if an action is configured to run on all PRs. People have abused this to run crypto miners and stuff in the past, but this for the most part is merely an annoyance to maintainers, not a security problem. It does become a security problem when arbitrary code execution is allowed with your secrets, including your configured secrets and the read/write GITHUB_TOKEN.
Expanding on the topic of secrets, if you trigger your test from the usual pull_request event, the workflow won't have access to GITHUB_TOKEN or configured secrets, so it's the safe default you should almost always choose. That becomes a problem when you need write access to the repo, e.g. to assign labels or add comments to the PR from the workflow, in which case you have to use the privileged pull_request_target event to expose GITHUB_TOKEN and secrets. pull_request_target by default runs in the context of the base of the PR, so there's still no arbitrary code, but you can explicitly check out the PR in that context, and when you do, your secrets are potentially exposed to arbitrary code. If you execute that arbitrary code in any job, or like in this case, post the content of effectively any file on disk as directed by an attacker, boom, owned.
Therefore, you should
- Avoid pull_request_target unless white access to the repo and/or access to configured secrets is absolutely necessary;
- When using pull_request_target, avoid checking out untrusted code;
- If it's absolutely necessary to check out untrusted code, make absolutely sure that the untrusted code isn't executed in any way, and that your trusted handling code can't be tricked by untrusted content in any way, like an arbitrary symlink. This is of course difficult to verify.
In this specific case, the fix seems to be checking that the absolute path of the untrusted advice.txt is within GITHUB_WORKSPACE (https://github.com/check-spelling/check-spelling/commit/4363...). IMO that's a wrong fix only covering the symptom. The real cause is using untrusted configuration files at all; why not make a copy of the trusted version of configuration files and use those instead???
GitHub has an article about security considerations here: https://securitylab.github.com/research/github-actions-preve...
cert-manager
-
deploying a minio service to kubernetes
cert-manager
-
Upgrading Hundreds of Kubernetes Clusters
The second one is a combination of tools: External DNS, cert-manager, and NGINX ingress. Using these as a stack, you can quickly deploy an application, making it available through a DNS with a TLS without much effort via simple annotations. When I first discovered External DNS, I was amazed at its quality.
-
Run WebAssembly on DigitalOcean Kubernetes with SpinKube - In 4 Easy Steps
On top of its core components, SpinKube depends on cert-manager. cert-Manager is responsible for provisioning and managing TLS certificates that are used by the admission webhook system of the Spin Operator. Letβs install cert-manager and KWasm using the commands shown here:
-
Importing kubernetes manifests with terraform for cert-manager
terraform { required_providers { kubectl = { source = "gavinbunney/kubectl" version = "1.14.0" } } } # The reference to the current project or a AWS project data "google_client_config" "provider" {} # The reference to the current cluster or EKS data "google_container_cluster" "my_cluster" { name = var.cluster_name location = var.cluster_location } # We configure the kubectl provider to use those values for authenticating provider "kubectl" { host = data.google_container_cluster.my_cluster.endpoint token = data.google_client_config.provider.access_token cluster_ca_certificate = base64decode(data.google_container_cluster.my_cluster.master_auth[0].cluster_ca_certificate) } #Download the multiple manifests file. data "http" "cert_manager_crds" { url = "https://github.com/cert-manager/cert-manager/releases/download/v${var.cert_manager_version}/cert-manager.crds.yaml" } data "kubectl_file_documents" "cert_manager_crds" { content = data.http.cert_manager_crds.response_body lifecycle { precondition { condition = 200 == data.http.cert_manager_crds.status_code error_message = "Status code invalid" } } } # We use the for_each or else this kubectl_manifest will only import the first manifest in the file. resource "kubectl_manifest" "cert_manager_crds" { for_each = data.kubectl_file_documents.cert_manager_crds.manifests yaml_body = each.value }
-
An opinionated template for deploying a single k3s cluster with Ansible backed by Flux, SOPS, GitHub Actions, Renovate, Cilium, Cloudflare and more!
SSL certificates thanks to Cloudflare and cert-manager
-
Deploy Rancher on AWS EKS using Terraform & Helm Charts
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/${CERT_MANAGER_VERSION}/cert-manager.crds.yaml
-
Setup/Design internal PKI
put the Sub-CA inside hashicorp vault to be used for automatic signing of services like https://cert-manager.io/ inside our k8s clusters.
-
Task vs Make - Final Thoughts
install-cert-manager: desc: Install cert-manager deps: - init-cluster cmds: - kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/{{.CERT_MANAGER_VERSION}}/cert-manager.yaml - echo "Waiting for cert-manager to be ready" && sleep 25 status: - kubectl -n cert-manager get pods | grep Running | wc -l | grep -q 3
-
Easy HTTPS for your private networks
I've been pretty frustrated with how private CAs are supported. Your private root CA can be maliciously used to MITM every domain on the Internet, even though you intend to use it for only a couple domain names. Most people forget to set Name Constraints when they create these and many helper tools lack support [1][2]. Worse, browser support for Name Constraints has been slow [3] and support isn't well tracked [4]. Public CAs give you certificate transparency and you can subscribe to events to detect mis-issuance. Some hosted private CAs like AWS's offer logs [5], but DIY setups don't.
Even still, there are a lot of folks happily using private CAs, they aren't the target audience for this initial release.
[1] https://github.com/FiloSottile/mkcert/issues/302
[2] https://github.com/cert-manager/cert-manager/issues/3655
[3] https://alexsci.com/blog/name-non-constraint/
[4] https://github.com/Netflix/bettertls/issues/19
[5] https://docs.aws.amazon.com/privateca/latest/userguide/secur...
-
βΈοΈ Managed Kubernetes : Our dev is on AWS, our prod is on OVH
the Cert Manager
What are some alternatives?
did_you_mean - The gem that has been saving people from typos since 2014
metallb - A network load-balancer implementation for Kubernetes using standard routing protocols
advisories
aws-load-balancer-controller - A Kubernetes controller for Elastic Load Balancers
PHP-Spellchecker - πππ PHP Library providing an easy way to spellcheck multiple sources of text by many spellcheckers
Portainer - Making Docker and Kubernetes management easy.
ohmyzsh - π A delightful community-driven (with 2,300+ contributors) framework for managing your zsh configuration. Includes 300+ optional plugins (rails, git, macOS, hub, docker, homebrew, node, php, python, etc), 140+ themes to spice up your morning, and an auto-update tool so that makes it easy to keep up with the latest updates from the community.
awx-operator - An Ansible AWX operator for Kubernetes built with Operator SDK and Ansible. π€
Windows Terminal - The new Windows Terminal and the original Windows console host, all in the same place!
k3s - Lightweight Kubernetes
winget-cli - WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
oauth2-proxy - A reverse proxy that provides authentication with Google, Azure, OpenID Connect and many more identity providers.