Background Jenkins custom resources on a Kubernetes cluster are deployed using declarative YAML configuration files; hence some of the plugins declared in these files may contain security warnings. So there is no way for the user to know other than manually checking for each on the site. This project aims to add an extra step of validation before creating/updating a new Jenkins Custom Resource. Deliverables This project aims to add a validating admission webhook to the Jenkins Operator for Kubernetes to detect potential security vulnerabilities in the plugins before the object is created. Dependencies Webhooks communicate to the API server over HTTPS and use TLS. Thus, Jetstack/cert-manager is used to provision TLS certificates and establish connection between Kubernetes API and webhook. Implementaion Operator-SDK takes care of creating a new webhook and appending it to the manager and creating handlers. Tls certificates are managed using cert-manager. Validation Logic: Proposed Implementations: Iterate through the list of plugins to be installed and fetch warnings for each plugin from the plugin center API and check if the version of that plugin has any of those warnings. Caveats: Webhooks add latency to an API request, hence they should evaluate as quickly as possible thus having max allowed timeout of 30s. In the earlier approach I was fetching the security warnings from the plugin site API in the validator interface itself, and since network operations are slow, it was causing a timeout in the case of validating a larger number of plugins or when the Internet connection was not good. Updated Implementaion: Instead of fetching information for each plugin, the information about all the plugins is downloaded and cached at the start of the operator and updated periodically, thus eliminating network calls and finishing validation in less than a second. Evaluation Phase 1: Scaffoled a new validation webhook Added manifests for ValidatingWebhookConfiguration, certificates and volumes, and updated Makefile Implemented the validator interface Updated helm charts Evaluation Phase 2: Reimplemented the validator interface. Added unit tests for internal functions Added e2e tests along with helm tests Updated helm charts Resources Pull Requests Added validation webhook,manifests,and updated Makefile Implemented validation logic,added tests and updated helm charts Phase 1 demo User Guide The webhook feature is completely optional for the user. It can be easily deployed using Helm Chart by setting webhook.enabled in values.yaml and in the Operator command line flag. webhook.enabled=true To enable security validation in the jenkins custom resource set jenkins.ValidateSecurityWarnings=true Note: The webhook takes some time to get up and running, also when helm renders the template, the validating webhook configuration is applied last, hence if the user wants to deploy the Jenkins Custom Resource with validation turned on, he needs to wait for some time. After the webhook is up and running the user can deploy the Jenkins Custom Resource using helm or kubectl Future work Implementing a post-install hook in the helm charts that checks whether the webhook is up and running. Adding validation for required core version of plugin and core version of Jenkins. Migrating other validation logic from controller to the webhook. Adding validation for the dependencies of the plugins.