{"id":48084422,"url":"https://github.com/upbound/kubernetes-cedar-authorizer","last_synced_at":"2026-04-04T15:07:06.145Z","repository":{"id":307479741,"uuid":"1022100474","full_name":"upbound/kubernetes-cedar-authorizer","owner":"upbound","description":"Proof of Concept of a Conditional Authorizer for Kubernetes using Cedar. Work in progress","archived":false,"fork":false,"pushed_at":"2025-08-27T11:29:56.000Z","size":899,"stargazers_count":3,"open_issues_count":31,"forks_count":1,"subscribers_count":0,"default_branch":"main","last_synced_at":"2025-08-27T20:38:58.392Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Rust","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/upbound.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null}},"created_at":"2025-07-18T13:02:14.000Z","updated_at":"2025-08-27T18:10:06.000Z","dependencies_parsed_at":"2025-07-31T15:06:10.745Z","dependency_job_id":"ae285635-e76d-4c72-a5eb-e1677fc30792","html_url":"https://github.com/upbound/kubernetes-cedar-authorizer","commit_stats":null,"previous_names":["upbound/kubernetes-cedar-authorizer"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/upbound/kubernetes-cedar-authorizer","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/upbound%2Fkubernetes-cedar-authorizer","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/upbound%2Fkubernetes-cedar-authorizer/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/upbound%2Fkubernetes-cedar-authorizer/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/upbound%2Fkubernetes-cedar-authorizer/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/upbound","download_url":"https://codeload.github.com/upbound/kubernetes-cedar-authorizer/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/upbound%2Fkubernetes-cedar-authorizer/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":31403952,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-04-04T10:20:44.708Z","status":"ssl_error","status_checked_at":"2026-04-04T10:20:06.846Z","response_time":60,"last_error":"SSL_read: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-04-04T15:07:05.457Z","updated_at":"2026-04-04T15:07:06.137Z","avatar_url":"https://github.com/upbound.png","language":"Rust","funding_links":[],"categories":[],"sub_categories":[],"readme":"# kubernetes-cedar-authorizer\n\nProof of concept integrating [Cedar] with [Kubernetes], leveraging in particular\nthe [Typed Partial Evaluation feature] of Cedar, in order to unify Kubernetes\nauthorization and admission request stages. The design for this work is found in\nmy [MSc thesis], please read that work to understand the context. Slides from\nthe MSc thesis presentation are available [here][thesis-presentation].\n\nThis project is intended to be merged into\n[Cedar Access Control for Kubernetes] when/if this experiment proves viable. In\naddition, this project serves as a temporary playground for experimenting with\nhow/if Kubernetes could add support for Conditional Authorization, discussed for\nexample in this [SIG Auth meeting]. Hopefully, a Kubernetes Enhancement Proposal\ncould be written for the Conditional Authorization, given promising enough\nresults here and/or later in Cedar Access Control for Kubernetes.\n\nLet Lucas know if you have feedback or ideas.\n\n**NOTE:** This project is an experiment, and is not yet ready for production\nuse. Do not under any circumstances use it in production. This is not an Upbound\nproduct.\n\n## Context\n\nBy design, Kubernetes authorization operates only on _metadata_, on attributes\nthat can be inferred from the URL without deserializing the request payload.\nThis means that Kubernetes authorizers can offer users pretty limited\nexpressitivity. However, later in the admission stage, more data is available,\nfor example, the request body and currently stored object in etcd. In order to\nwrite an authorization policy which targets both metadata and data, a user must\nuse two different paradigms: Kubernetes RBAC and ValidatingAdmissionPolicy (VAP).\n\nEven though the policy author would manage to coordinate the two policy types to\nyield a unified result, there are limitations, due to e.g. admission only being\ninvoked for write requests. In addition, it is hard to understand what the\neffective set of access is, if one takes both RBAC and admission into account.\n\nThe idea with this project is to experiment with and demonstrate how Kubernetes\nauthorization and admission could get new capabilities and an improved UX by\nintegrating with Cedar.\n\n## Motivation\n\n- Allow one uniform user interface across both authorization and admission.\n  Allow a policy author to write an authorization policy that only applies if\n  some property of the request payload, stored object in etcd, or namespace\n  metadata holds. For example,\n  - only allow a principal to create `CertificateSigningRequests` with a given\n    signer, or\n  - only allow a principal to update a resource as long as a sensitive field is\n    not changed, or\n  - only allow a principal to issue a `ServiceAccount` token with a given\n    audience, or\n  - only allow a controller to use a specific finalizer.\n- Allow limiting the lists and watches to only return resources with certain\n  field and label values, using the exact same syntax as for write requests.\n  - For example, only allow Gateway/Ingress controllers to list `Secrets` of\n    `.type=kubernetes.io/tls` and/or with label `ingress-bindable=true`\n  - This is basically a uniform interface for expressing policies using the\n    [Authorize with Selectors KEP]\n- Allow more expressiveness than RBAC's\n  `bound_rule1 || bound_rule2 || ... || bound_ruleN`, where a rule is logically\n  `api_group_matches \u0026\u0026 combinedresource_matches \u0026\u0026 namespace_matches \u0026\u0026 name_matches`.\n  - Allow binding some data from the user in the condition for what\n    kind of resource matches.\n  - For example, only allow a node agent to handle resources where\n    `.spec.nodeName=\u003cbound-node\u003e`.\n  - Allow string matching (principal name, resource name(space)) by prefix or suffix.\n  - Absence of prefix matching is discussed in [kubernetes#122154] and\n    [kubernetes#56582] (for better and worse, subdiving namespaces is still not\n    a good idea).\n- Expose the UserInfo `uid` and `extra` fields to the policy author.\n- Allow for more fine-grained impersonation. Today, one can only express whether\n  a principal can impersonate a given UserInfo attribute independently of all\n  other impersonated values. In addition, it is not possible to constrain the\n  impersonation to only apply for a given verb or resource.\n  - [Constrained Impersonation] is useful e.g. for letting a node agent\n    impersonate the node it is running on to get access to a limited set of the\n    node's linked resources (e.g. Pods, Secrets, etc.)\n  - Combining fine-grained impersonation with string prefix matching allows for\n    limiting the permissions of an authenticating front proxy (e.g.\n    [kube-oidc-proxy]). Without prefix matching, most likely the RBAC rule\n    giving the front proxy ability to impersonate allows impersonating all\n    groups, including `system:masters` which gives effectively root cluster\n    access, which is most likely not desired.\n- Make authoring a policy across authorization and admission stage atomic. In\n  other words, make it impossible for e.g. the RBAC (allow) rule to apply when\n  the VAP (deny) rule does not (yet).\n- Allow restricting the names that can be used when creating an API object\n  (including when using `generateName`) [kubernetes#54080]\n- Potentially, in the future, allow for writing a limited set of deny rules.\n\n## Goals\n\n- 100% compability with Kubernetes RBAC\n- Support any built-in Kubernetes and CRD resource and subresource.\n- Fast, bounded policy evaluation time.\n- Seamless integration with the Kubernetes API server, and the existing CEL\n  infrastructure, by converting from Cedar to CEL where needed.\n- Improve the user experience for policy authors, e.g. by instant feedback\n  (validation, syntax highlighting, autocompletion, and linting) in the IDE\n  (e.g. VS Code)\n- Support writing policies simultaneously against multiple API versions of the\n  API object, and seamless up- and downgrades.\n- Privilege escalation prevention support.\n- Allow [mathematical analysis] of the Kubernetes authorization state using SMT\n  solvers, based on the [Cedar Symbolic Compiler].\n  - This allows e.g. for finding logical inconsistencies in the policies,\n    checking if a refactor was done correctly (are the policies before\n    mathematically equivalent to the policies after), and more.\n- Allow for principal and resource querying, that is, asking for example:\n  - \"What resources can principal P perform what actions on?\"\n  - \"What principals can perform what actions on resource R?\"\n  - This is useful for auditing that the end result of all policies combined\n    indeed are the desired result.\n- Allow increasing expressivity without forcing the cluster administrator to\n  build their custom webhook authorizer, which is (understandably) not supported\n  in most hosted Kubernetes distributions.\n- Don't reinvent the wheel. Use the unique strengths of Cedar and CEL, and the\n  vast effort that have gone into SMT solver implementation and research.\n\n## Why Cedar?\n\nCedar is an authorization engine and policy language that is designed to be\nexpressive, fast, safe, analyzable. The language has a [formal specification],\nand the implementation is [formally verified to conform] to the specification.\n[Cedar is open source], Apache 2.0 licensed, and is in the\n[process of being donated to the CNCF]. Effectively, Cedar is a stateless\nauthorization library, written in Rust, and can thus be integrated into almost\nany environment. This project utilizes Cedar to solve challenges encountered in\nKubernetes authorization.\n\nSee the [Cedar website] for more information. In Lucas' opinion, the best\nresource on how Cedar works and is designed in detail, is the\n[Cedar OOPSLA paper].\n\nA couple of critical features of Cedar are:\n\n- The [Typed Partial Evaluation feature], which (while only supplying metadata)\n  empowers denying such requests, where there is either at least one deny policy\n  that is guaranteed to evaluate to true, or all allow policies are guaranteed\n  to evaluate to false.\n- The [Cedar Symbolic Compiler], which translates Cedar policies into\n  mathematical logic, more precisely, [SMT-LIB] format.\n- The typed schema, which allows for type-safe policies, and for the policy\n  author to reason about the policy in the IDE using the [Cedar IDE plugin].\n\n## Quickstart\n\nInstall [kind] v0.29.0 and [kubectl] v1.33.0, e.g. through [Homebrew] on macOS:\n\n```console\n$ brew install kind kubectl\n...\n$ kind version\nkind v0.29.0 go1.24.6 darwin/arm64\n$ kubectl version               \nClient Version: v1.33.4\n```\n\nYou'll also need `make` and `docker` (or a CLI-compatible alternative, activate\nwith e.g. `DOCKER=podman make ...`).\n\nClone Lucas' Kubernetes fork, and checkout the `conditional_authz_2` branch:\n\n```bash\ncd .. # Go to the parent directory of this repository\ngit clone https://github.com/luxas/kubernetes.git\ncd kubernetes\ngit checkout conditional_authz_2\ncd ../kubernetes-cedar-authorizer\n```\n\nCompile Kubernetes from source:\n\n```bash\nkind build node-image /path/to/kubernetes/source --image kindest/node:luxas_conditional_authz_2_latest\n```\n\nNext, generate a self-signed certificate for the webhook server, and name the\ncert `server.crt` and the key `server.key`, and put them in the `localdev/mount/certs`\ndirectory. The certificate must be valid for the hostname `localhost`.\n\nNote: There is a thousand things that can fail when compiling Kubernetes from\nsource. For example, if you're on a Mac, you most likely need to install gnu tar\n(`brew install gnu-tar`), and set your default shell to bash from homebrew\n(`brew install bash`, `sudo ln -s \u003cbash install path\u003e /usr/local/bin/bash`, and\n`chpass -s /usr/local/bin/bash`) in order for kubernetes to compile correctly.\n\nFinally, we are ready to build the webhook image and start kind:\n\n```bash\nmake kind\n```\n\nThen, follow the [getting started guide].\n\n## Frequently Asked Questions\n\n### How does this project differ from the [Cedar Access Control for Kubernetes] project?\n\nThis project:\n\n- Provides the policy author with a uniform interface for expressing policies.\n  In the current Cedar Access Control for Kubernetes, the policy author must\n  author policies for authorization and admission separately.\n- Allows read and write policies to be authorized in a uniform way.\n- Showcases how atomically applicable policies can be written and enforced by\n  the Kubernetes core API server (as per Lucas'\n  [conditional_authz_2 Kubernetes branch]), instead of by twice by the webhook\n  (both at authorization and admission time).\n- Is written in Rust; Cedar Access Control for Kubernetes is written in Go.\n- Is aimed to be donated and merged into the\n  [Cedar Access Control for Kubernetes] project, if this experiment proves\n  valuable, and when Cedar is donated to the CNCF.\n\n[Cedar]: https://github.com/cedar-policy/cedar\n[Kubernetes]: https://github.com/kubernetes/kubernetes\n[MSc thesis]: https://github.com/luxas/research/blob/main/msc_thesis.pdf\n[Cedar Access Control for Kubernetes]: github.com/cedar-policy/cedar-access-control-for-k8s\n[Typed Partial Evaluation feature]: https://github.com/cedar-policy/rfcs/blob/main/text/0095-type-aware-partial-evaluation.md\n[thesis-presentation]: https://speakerdeck.com/luxas/usable-access-control-in-cloud-management-systems\n[SIG Auth meeting]: https://youtu.be/Clg-rz9qlUA\n[Constrained Impersonation]: https://github.com/kubernetes/enhancements/pull/5285\n[kube-oidc-proxy]: github.com/TremoloSecurity/kube-oidc-proxy\n[kubernetes#122154]: https://github.com/kubernetes/kubernetes/issues/122154\n[kubernetes#56582]: https://github.com/kubernetes/kubernetes/issues/56582\n[kubernetes#54080]: https://github.com/kubernetes/kubernetes/issues/54080\n[Authorize with Selectors KEP]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/4601-authorize-with-selectors\n[mathematical analysis]: https://aws.amazon.com/blogs/opensource/introducing-cedar-analysis-open-source-tools-for-verifying-authorization-policies/\n[Cedar Symbolic Compiler]: https://github.com/cedar-policy/cedar/tree/main/cedar-policy-symcc\n[Cedar website]: https://www.cedarpolicy.com/en\n[formal specification]: https://github.com/cedar-policy/cedar-spec/\n[formally verified to conform]: https://aws.amazon.com/blogs/opensource/lean-into-verified-software-development/\n[Cedar is open source]: https://github.com/cedar-policy/cedar\n[process of being donated to the CNCF]: https://github.com/cncf/sandbox/issues/371\n[Cedar OOPSLA paper]: https://www.amazon.science/publications/cedar-a-new-language-for-expressive-fast-safe-and-analyzable-authorization\n[SMT-LIB]: https://smt-lib.org/\n[Cedar IDE plugin]: https://github.com/cedar-policy/vscode-cedar/\n[conditional_authz_2 Kubernetes branch]: https://github.com/luxas/kubernetes/tree/conditional_authz_2\n[Homebrew]: https://brew.sh/\n[kind]: https://kind.sigs.k8s.io/\n[kubectl]: https://kubernetes.io/docs/tasks/tools/#kubectl\n[getting started guide]: ./docs/GETTING_STARTED.md","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fupbound%2Fkubernetes-cedar-authorizer","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fupbound%2Fkubernetes-cedar-authorizer","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fupbound%2Fkubernetes-cedar-authorizer/lists"}