A new version of CEL Playground has been released, now with extra Kubernetes flavour! Discover and try the new CEL modes: Validating Admission Policy and WebHooks.
Chief Engineer
Kevin Conner
TL;DR
Uma nova versão do CEL Playground foi lançada, agora com um toque extra de Kubernetes! Experimente os novos modos do CEL e teste o suporte a ValidatingAdmissionPolicy e WebHook do Kubernetes em ambientes focados. Continue lendo para uma introdução detalhada aos novos recursos, incluindo exemplos práticos que demonstram o suporte inicial ao Kubernetes.
Contexto
A Common Expression Language (CEL) é uma linguagem de expressão de código aberto, não Turing-completa, criada pelo Google. A CEL está sendo adotada em muitas comunidades, inclusive no Kubernetes, onde está sendo usada para substituir mecanismos mais antigos e pesados por soluções leves que podem ser incorporadas e executadas inline.
O CEL Playground é um ambiente baseado em navegador que nasceu de uma necessidade: ter um espaço seguro para aprender como a Common Expression Language pode ser usada.
Introdução
Faz quase um ano que Matheus Faria começou a buscar uma solução para ajudar os usuários a aprender, experimentar e testar expressões CEL. Seu interesse surgiu de seu trabalho no projeto de código aberto marvin, uma ferramenta de CLI que identifica problemas e configurações incorretas por meio da avaliação de expressões CEL nos recursos de um cluster, bem como da crescente adoção do CEL em vários componentes do Kubernetes.
Matheus pesquisou para ver o que já estava disponível, perguntando a outros membros da comunidade do Kubernetes como eles trabalhavam com expressões CEL, mas não conseguiu encontrar nada que atendesse a essa necessidade. O que ele descobriu foi um grande interesse da comunidade em ter algo que preenchesse essa lacuna.
Esse interesse motivou a criação do CEL Playground, e o desenvolvimento começou em junho de 2023. O projeto rapidamente ganhou forma no mês seguinte e logo tivemos um playground baseado em navegador onde podíamos aprender, experimentar e testar expressões CEL.
O projeto foi apresentado a várias comunidades, incluindo os Grupos de Interesse Especial (SIGs) de API Machinery e Auth do Kubernetes, bem como ao OpenShift Commons, e buscamos feedback sobre como melhorar e desenvolver ainda mais o playground.
O pedido mais popular, de longe, foi estender o playground com um suporte melhor para casos de uso do Kubernetes, especialmente ValidatingAdmissionPolicy e Webhooks.
O projeto também foi mencionado em várias palestras do KubeCon e do Cloud Native Rejekts
CEL Playground: a Próxima Geração
Estamos muito empolgados em anunciar a próxima grande versão do CEL Playground, que apresenta muitos recursos de suporte aos casos de uso do Kubernetes. Esta versão se concentra principalmente nos casos de uso do Kubernetes de Validating Admission Policy e Admission Webhook, mas também traz melhorias na interface para permitir a alternância de modos dependendo do caso de uso desejado.
Suporte para Modos de Expressão CEL
A versão atualizada da interface do CEL Playground agora inclui a capacidade de mudar para um modo diferente dependendo do seu caso de uso. O modo pode ser alterado selecionando o botão "Modes" no canto superior esquerdo da interface do usuário
Isso exibirá uma caixa de diálogo que permite que você escolha o seu modo de avaliação de expressão
Os modos suportados atualmente são:
CEL Expression
Este modo suporta os recursos originais de avaliação do CEL, permitindo executar uma expressão CEL com um conjunto específico de valores de entrada.
Validating Admission Policy
Este modo oferece suporte para avaliar as Políticas de Admissão de Validação (Validating Admission Policies), avaliando as expressões CEL dentro de uma instância do recurso ValidatingAdmissionPolicy e suportando as seguintes variáveis de entrada contextual:
object - O objeto da solicitação de entrada. O valor deve estar vazio para solicitações DELETE.
oldObject - O objeto existente. O valor deve estar vazio para solicitações CREATE.
request - Atributos da solicitação de API.
namespaceObject - O objeto namespace ao qual o objeto de entrada pertence. O valor deve estar vazio para recursos de escopo de cluster.
authorizer - Um simulador de autorizador CEL (mock). Pode ser usado para realizar verificações de autorização para o principal da solicitação (usuário ou conta de serviço).
authorizer.requestResource - O ResourceCheck do CEL que representa o recurso da solicitação.
A integração atualmente não suporta parâmetros, no entanto, isso será incorporado em uma versão futura.
Web Hooks
Este modo oferece suporte para avaliar matchConditions de webhook de admissão, avaliando as expressões CEL dentro de uma instância dos recursos ValidatingWebhookConfiguration ou MutatingWebhookConfiguration. Esta integração suporta a maioria das variáveis de entrada contextual mencionadas na seção anterior de ValidatingAdmissionPolicy, com exceção de namespaceObject e variáveis que não se aplicam.
Hora de se aprofundar:
Agora é hora de mergulhar nos detalhes do que é possível fazer atualmente nesses novos modos, prepare-se e vamos lá!
Variáveis de Entrada Contextuais
Os novos modos utilizam variáveis de entrada contextualizadas, localizadas na área superior direita da interface do usuário. Essas variáveis representam as informações disponibilizadas pelas integrações específicas do Kubernetes para avaliar suas expressões CEL associadas.
Object e Old Object
As variáveis de entrada contextual Object e Old Object, referenciadas nas expressões CEL pelos nomes object and oldObject, representam o recurso do Kubernetes associado à solicitação de entrada, com seu conteúdo relacionado à operação que está sendo realizada.
Para operações CREATE, a variável Object conterá o novo valor do recurso que está sendo aplicado na operação, e a variável Old Object estará vazia.
Para operações UPDATE, a variável Old Object conterá o valor atual do recurso, e a variável Object conterá a nova versão sendo aplicada na atualização.
Para operações DELETE, a variável Old Object conterá o valor atual do recurso, e a variável Object estará vazia.
Para operações UPDATE, os valores em Object e Old Object devem ser consistentes, referenciando o mesmo tipo e nome de recurso. Por exemplo, se a política está sendo aplicada a um apps/v1/Deployment, ambas as variáveis de entrada contextual devem ser desse tipo.
As variáveis de entrada contextual Object e Old Object são usadas tanto no modo ValidatingAdmissionPolicy quanto no modo WebHook.
Namespace
A variável de entrada contextual Namespace, referenciada nas expressões CEL pelo nome namespaceObject, contém o recurso namespace do Kubernetes associado ao recurso referenciado em Object e Old Object.
A variável de entrada contextual Namespace é usada no modo ValidatingAdmissionPolicy, porém não é necessária no modo Webhook.
Request
A variável de entrada contextual Request, referenciada nas expressões CEL pelo nome request, contém a parte AdmissionRequest do recurso admission.k8s.io/v1/AdmissionReview, com exceção dos campos object e oldObject que estão disponíveis separadamente.
O AdmissionRequest contém informações relacionadas a:
O identificador exclusivo da solicitação
O Kind do objeto de entrada
O recurso de destino e subrecurso da operação
O kind/resource/subresource original caso a informação tenha sido convertida
O nome e namespace do recurso
O tipo de operação
Informações sobre o usuário que está fazendo a solicitação
Se trata-se de uma solicitação em modo de teste (dry-run)
Informações de opção associadas à operação
Para obter mais informações sobre a estrutura deste recurso, consulte a documentação do Kubernetes
A variável de entrada contextual Request é usada tanto no modo ValidatingAdmissionPolicy quanto no modo WebHook.
Authorizer
A variável de entrada contextual Authorizer, referenciada em expressões CEL pelo nome authorizer, fornece informações que podem ser usadas para simular o comportamento de um autorizador do Kubernetes. Esse comportamento inclui a criação de decisões com base em verificações de um caminho específico, de um recurso específico e usando uma conta de serviço específica. A decisão fornecerá informações sobre se a verificação específica foi permitida, o motivo da resposta ou informações sobre qualquer erro que possa ter ocorrido.
A variável de entrada contextual Authorizer é usada tanto no modo ValidatingAdmissionPolicy quanto no modo WebHook.
Verificações de Caminho (Path)
As verificações de caminho permitem que a expressão CEL avalie a decisão de autorização para acessar um caminho específico e um verbo HTTP específico
authorizer.path(‘/health’).check(‘get”)
retornará uma decisão com base no fato de o Principal atual poder executar uma operação GET no caminho /health
Verificações de Recursos (Resource)
As verificações de recursos permitem que as expressões CEL avaliem uma decisão de autorização para o acesso a um tipo específico de recurso. Essas verificações podem ser ainda mais restritas para avaliar o acesso a um subrecurso, namespace, nome específico ou uma combinação deles.
A verificação é realizada para uma operação específica no recurso, por exemplo:
authorizer.group(‘apps’).resource(‘deployment’).check(‘create’)
retornará uma decisão baseada no fato de o Principal atual poder criar um recurso de deployment
authorizer.group(‘apps’).resource(‘deployment’).subresource(‘scale’). check(‘update’)
retornará uma decisão com base no fato de o Principal atual poder atualizar o subrecurso scale para um deployment
authorizer.group(‘apps’).resource(‘deployment’).namespace(‘default’). check(create’)
retornará uma decisão com base no fato de o Principal atual poder criar um recurso de deployment dentro do namespace default
authorizer.group(‘apps’).resource(‘deployment’).name(‘myresource’). check(‘update’)
retornará uma decisão baseada no fato de o Principal atual poder atualizar um recurso de deployment chamado myresource
Nota: subresource, namespace e name podem ser usados em qualquer combinação antes de invocar o método check
Contas de Serviço (Service Accounts)
As verificações de Conta de Serviço permitem que a expressão CEL avalie se uma conta de serviço específica tem permissão para acessar caminhos ou recursos. Isso é feito especificando os dados da conta de serviço antes da verificação do caminho ou recurso relevante.
authorizer.serviceAccount('default', 'myserviceaccount').group(‘apps’). resource(‘deployment’).check(‘create’)
retornará uma decisão baseada no fato de a conta de serviço chamada myserviceaccount dentro do namespace default poder criar um recurso de deployment
authorizer.serviceAccount('default', 'myserviceaccount').path(‘/health’). check(‘get”)
retornará uma decisão com base no fato de a conta de serviço chamada myserviceaccount dentro do namespace default poder executar uma operação GET no caminho /health.
Decisões
Uma decisão será retornada pelas chamadas de check descritas nas seções anteriores, e essa decisão pode ser testada para verificar o sucesso da verificação. Há quatro métodos que podem ser chamados no objeto de decisão, que são:
authorizer.group(‘apps’).resource(‘deployment’).check(‘create’).allowed()
retornará verdadeiro se o Principal atual puder criar um recurso de deployment
authorizer.group(‘apps’).resource(‘deployment’).check(‘create’).reason()
retornará uma string explicando o motivo da decisão da verificação solicitada
authorizer.group(‘apps’).resource(‘deployment’).check(‘create’).errored()
retornará verdadeiro se a verificação resultar em erro
authorizer.group(‘apps’).resource(‘deployment’).check(‘create’).error()
retornará uma string detalhando o erro, caso tenha ocorrido um
Formato da Entrada Contextual do Autorizador
O formato de entrada contextual do Authorizer é específico do CEL Playground e simula as informações e as chamadas de métodos suportadas pelo autorizador para chegar a uma decisão. O valor deve seguir esta estrutura:
Nota: Os colchetes angulares (< >) são usados para representar nomes de itens específicos, que também podem ser repetidos desde que os nomes permaneçam distintos. Os valores <namespace> e <name> dentro das seções checks também podem usar uma string vazia para indicar que não são necessários.
Exemplos
Agora que cobrimos as variáveis contextuais de entrada, podemos analisar alguns exemplos práticos.
Exemplos de Validating Admission Policy
O CEL Playground suporta a avaliação de expressões CEL nas seguintes seções de ValidatingAdmissionPolicy:
match conditions (condições de correspondência)
variables (variáveis)
validations e suas expressões de mensagem (validations e message expressions)
audit annotations (anotações de auditoria)
Veremos agora com mais detalhes alguns exemplos dessas seções. Acesse o CEL Playground e selecione o modo ValidatingAdmissionPolicy.
Match Conditions (Condições de Correspondência)
As Match Conditions determinam se a ValidatingAdmissionPolicy se aplica a uma determinada solicitação. Suas regras são as seguintes:
Se qualquer matchCondition for avaliada como false, a política será ignorada.
Se todas as matchConditions forem avaliadas como true, a política será avaliada.
Se uma matchCondition gerar um erro, o resultado final será determinado pela failurePolicy.
Nota: atualmente não verificamos a failurePolicy quando ocorrem erros; retornamos informações sobre o erro e baseamos a decisão nos resultados das outras matchConditions.
Vejamos agora um exemplo prático das Condições de Correspondência. Escolha a opção Match Conditions na lista de exemplos para começar.
Este exemplo contém duas matchConditions e uma validation. As matchConditions são:
exclude-leases
Esta matchCondition será avaliada como true se o request.resource.group não for “coordination.k8s.io” ou se o request.resource.resource não for “leases”.
exclude-kubelet-requests
Esta matchCondition será avaliada como true se request.userInfo.groups não contiver o grupo “system:nodes”.
Agora executaremos a avaliação para ver o que acontece. Se expandirmos cada seção no painel de saída, obteremos os seguintes resultados:
Esses resultados mostram que ambas as matchConditions foram avaliadas como true. Com isso, a política é aplicada à solicitação e as regras de validação também são avaliadas.
Podemos ver o custo de cada avaliação, retornado pela biblioteca CEL, bem como o custo total da avaliação de todas as expressões.
Agora vamos fazer com que uma das matchConditions falhe para ver o que acontece. Para fazer isso, faremos com que a matchCondition exclude-kubelet-requests seja avaliada como false, o que conseguimos adicionando o grupo “system:nodes” às informações do usuário da solicitação.
Escolha a entrada condicional Request
Role para baixo até a seção userInfo
Adicione system:nodes à lista de grupos (groups)
Se executarmos a avaliação agora, deveremos obter os seguintes resultados:
Como podemos notar, a matchCondition exclude-kubelet-requests agora é avaliada como false e as validações da política não são mais avaliadas.
Variáveis
As variáveis podem ser definidas dentro de uma ValidatingAdmissionPolicy, permitindo que expressões sejam avaliadas on demand (sob demanda) e reutilizadas em outras expressões.
Vejamos agora um exemplo das variáveis em ação. Escolha a opção Variables in Validation na lista de exemplos para começar.
Este exemplo contém quatro variáveis e uma validação. As variáveis são:
environment
Se o namespaceObject.metadata.labels contiver um rótulo com o nome “environment”, a variável assumirá o valor desse rótulo. Se o rótulo não existir, a variável adotará o valor padrão “prod”.
exempt
Esta variável será verdadeira se o object.metadata.labels contiver um rótulo chamado “exempt” e o valor desse rótulo for “true”.
containers
Esta variável conterá uma lista dos contêineres especificados em object.spec.template.spec.containers.
containersToCheck
Esta variável conterá uma lista de todos os contêineres que incluem “example.com/” no nome da imagem. Note que a expressão para esta variável utiliza a variável anterior, containers.
Agora executaremos a avaliação para ver o que acontece. Se expandirmos cada seção no painel de saída, obteremos os seguintes resultados:
E também:
Podemos ver a avaliação de todas as variáveis, seus respectivos custos e a avaliação da expressão de validação.
Agora vamos demonstrar o comportamento sob demanda da avaliação de variáveis.
Observando a expressão usada na validação, vemos que ela primeiro faz referência à variável exempt e depois usa a variável containersToCheck (que usa a variável containers) para verificar se todos os nomes de imagem começam com o valor da variável_environment_ seguido por um ponto. Podemos perceber também que, se a variável exempt retornar true, o CEL não avaliará o lado direito da expressão lógica OU (||), pois ela já retornará true de qualquer forma.
Vamos fazer com que a variável exempt seja avaliada como true para ver o que acontece. Conseguimos isso definindo um rótulo "exempt" como true no Object.
Selecione a entrada condicional Object
Role de tela até a seção labels e encontre o rótulo "exempt"
Mude o valor do rótulo para true
Se rodarmos a avaliação agora, o resultado apresentado deverá ser o seguinte:
Como podemos observar, apenas a variável exempt está sendo avaliada agora, pois ela é suficiente para determinar o resultado da expressão de validação. Como as demais variáveis nunca são acessadas, suas expressões não serão avaliadas.
Validations e as Expressões de Mensagem (Message Expressions)
As validações têm a opção de retornar uma mensagem descritiva ao cliente que faz a solicitação se a validação falhar. Para demonstrar esse comportamento, utilizaremos o mesmo exemplo Variables in Validation. Selecione-o novamente para restaurar os valores padrão do exemplo.
Com base na seção anterior, vemos que a validação retornará true se a variável exempt for true ou se todos os contêineres na variável containersToCheck tiverem uma imagem que comece com o valor da variável environment seguido por um ponto. O valor da variável environment vem dos rótulos no namespaceObject, que atualmente é avaliado como “prod”.
Para fazer a validação falhar, precisamos garantir que o nome da imagem comece com o nome de um ambiente diferente. Neste exemplo, escolheremos "demo".
Selecione a entrada condicional Object
Role até a seção de contêineres e procure pelo nome da imagem
Altere o nome da imagem para que comece com demo em vez de prod
Ao executar a avaliação agora, devemos obter os seguintes resultados:
E também:
Observando a resposta da validação, vemos que ela agora está retornando uma mensagem ao emissor, o que fornece uma explicação mais clara do motivo da falha. Essa mensagem é gerada a partir de uma expressão e, neste exemplo, a expressão faz referência à variável environment (prod) e ao namespaceObject.metadata.name para criá-la.
Anotações de Auditoria (Audit Annotations)
Quando uma ValidatingAdmissionPolicy permite que uma operação prossiga (ou seja, quando as validações têm sucesso), o Kubernetes gera um evento de auditoria correspondente. A ValidatingAdmissionPolicy oferece a capacidade de enriquecer o evento de auditoria incluindo anotações que trazem mais informações contextuais ao histórico de auditoria.
Veremos agora um exemplo das anotações de auditoria em ação. Selecione a opção Audit Annotations na lista de exemplos para começar.
Ao executar a avaliação, devemos obter os seguintes resultados:
Podemos observar por esses resultados que a validação foi bem-sucedida e que geramos uma anotação de auditoria com informações obtidas da solicitação, que neste exemplo utiliza o valor de object.spec.replicas.
Vejamos agora o comportamento quando a validação falha. Pela expressão de validação, percebe-se que ela espera que o número de réplicas seja maior que 50. Para fazer a validação falhar, realizaremos as seguintes alterações:
Selecione a entrada condicional Object
Role até a seção spec e procure pelo número de réplicas (replicas)
Mude a contagem para 3
Se rodarmos a avaliação agora, o resultado deverá ser o seguinte:
A partir da resposta da validação, podemos notar que ela falhou e retornou uma mensagem descrevendo o ocorrido; também podemos observar que nenhuma anotação de auditoria foi avaliada.
Exemplos de Webhook
O CEL Playground suporta a avaliação de expressões CEL nas seções de condições de correspondência (match conditions) dos recursos ValidatingWebHookConfigurations e MutatingWebhookConditions.
Vamos examinar matchConditions em mais detalhes. Acesse o CEL Playground e selecione o modo Web Hooks.
As Match Conditions determinam se os webhooks devem ser chamados para uma determinada solicitação. As regras são semelhantes às utilizadas na ValidatingAdmissionPolicy. Se as matchConditions forem avaliadas como true, o servidor da API do Kubernetes enviará a solicitação para o webhook para processamento adicional; caso contrário, o webhook não será chamado.
Nota: atualmente não verificamos a failurePolicy quando ocorrem erros; retornamos as informações sobre o erro e os resultados das outras matchConditions.
Vejamos agora um exemplo das Condições de Correspondência em ação. Selecione o exemplo Authorizer Ignore breakglass na lista para começar.
Este exemplo contém uma única matchCondition, “breakglass”. A matchCondition será avaliada como true se o autorizador determinar que o Principal atual não possui a permissão breakglass no recurso ValidatingWebhookCondition chamado "rbac.my-webhook.example.com". Se a matchCondition for avaliada como true, o serviço do webhook será invocado pelo servidor da API do Kubernetes.
Agora executaremos a avaliação para ver o que acontece. Se expandirmos cada seção da saída, teremos os seguintes resultados:
Neste exemplo, a matchCondition não correspondeu porque o Principal atual possui a permissão breakglass, portanto o webhook não será chamado.
Vamos alterar as informações da variável de entrada do Authorizer para que a matchCondition seja avaliada como true, fazendo com que o webhook seja chamado pelo servidor da API do Kubernetes. Realizaremos as seguintes alterações:
Selecione a entrada condicional do Authorizer
Role até o verbo breakglass nos recursos identificados
Mude a decisão para deny (negar)
Nota: atualmente a decisão é verificada para ver se corresponde ao valor “allow”, portanto, embora esperemos que o autorizador simulado use explicitamente allow e deny, no futuro será possível usar outros valores para negar a permissão.
Se rodarmos a avaliação agora, devemos obter os seguintes resultados:
Agora vemos que a matchCondition é avaliada como true e, portanto, seria esperado que o servidor da API do Kubernetes chamasse o webhook para processamento posterior.
Procura-se Ajuda
A introdução dos novos recursos do CEL Playground exigiu muito esforço, mas ainda estamos longe de terminar. Ainda há outros casos de uso do Kubernetes a serem considerados e muitas melhorias que podem ser feitas nos modos atuais. Essas tarefas incluem:
Definir como implementar recursos de parâmetros para avaliar as expressões da ValidatingAdmissionPolicy
Introduzir editores estruturados para as variáveis de Contextual Input
Incluir mais verificações de erros para simular o comportamento do Kubernetes
Existem muitas outras maneiras de melhorar o CEL Playground além das listadas acima, e o feedback da comunidade é uma parte crucial desse processo. Experimente os novos recursos e envie-nos o seu feedback. Isso pode incluir pedidos de melhorias, novos recursos que gostaria de ver implementados ou qualquer outra sugestão.
Ficaríamos muito felizes em receber novos colaboradores para o projeto. Se você tiver interesse em ajudar no desenvolvimento, entre em contato conosco.
Caso deseje mais informações ou queira participar, por favor:
Acesse o nosso repositório no GitHub
Participe do nosso canal no Slack
Participe das nossas reuniões abertas (Community Calls), que estão abertas a todos
E, por fim,
Gostaríamos de expressar nossa imensa gratidão a todos que colaboraram com o desenvolvimento do CEL Playground e desses novos recursos voltados ao Kubernetes. Recebemos ótimos feedbacks de membros do Kubernetes API Machinery SIG e do Kubernetes Auth SIG, em especial de Jordan Liggitt e Cici Huang.
Gostaríamos de incluir seu nome nessa lista, então junte-se a nós e ajude a aprimorar o CEL Playground da maneira que puder dedicas seu tempo.
Mais Informações
Os links a seguir fornecem mais detalhes sobre os casos de uso relacionados ao Kubernetes:
As gravações a seguir podem ser de seu interesse, pois demonstram e mostram a evolução do CEL Playground:
Apresentação do CEL Playground para o SIG de API Machinery do Kubernetes
Apresentação do CEL Playground para o SIG de Auth do Kubernetes
Apresentação do suporte inicial do Kubernetes no CEL e CEL Playground para o OpenShift Commons
Newsletter Getup.
Atualizações sobre Kubernetes e Software Supply Chain Security todos os meses.
Operating Kubernetes in production for more than 13 years. With Quor, this experience extends to software supply chain security as well.
GET UP
© Getup · 2026
