swift-policy-template

This is a template repository that can be used to to quickly scaffold a Kubewarden policy written with Swift language.

Don't forget to checkout Kubewarden's official documentation for more information about writing policies.

Introduction

This repository contains a working policy written in Swift.

The policy looks at the name of a Kubernetes resource and rejects the request if the name is on a deny list.

The deny list is configurable by the user via the runtime settings of the policy. The configuration of the policy is expressed via this structure:

{
  "deniedNames": [ "badname1", "badname2" ]
}

Code organization

The core of the policy can be found inside of the Sources/BusinessLogic directory. The Sources/Policy directory contains only the main of the policy.

The code that takes care of parsing the settings can be found inside of the settings.swift file.

The actual validation code is defined inside of the validate.swift file.

The main.swift contains only the code which registers the entry points of the policy.

Implementation details

DISCLAIMER: WebAssembly is a constantly evolving topic. This document describes the status of the Swift ecosystem at August 2022.

Currently the official Swift compiler cannot produce WebAssembly modules. This can be done by the SwiftWasm project. The SwiftWasm team is working to merge their changes upstream, inside of the official Swift compiler.

This is a list of libraries that can be useful when writing a Kubewarden policy:

• Manage JSON: JSON objects can be converted into native Swift objects by using the capabilities provided by the Foundation framework.
• Querying JSON data: the SwiftPath library can be used to extract data from JSON objects using JSONPath queries.
• Manage generic JSON structures: the GenericJSON library can be used for that.

Last but not least, this policy takes advantage of helper functions provided by Kubewarden's Swift SDK.

Testing

This policy comes with a set of unit tests.

As usual, the tests are defined inside of the Tests directory.

The unit tests can be run via a simple command:

make test

It's also a good idea to run end-to-end tests against the final policy.

This is done by a second set of end-to-end tests. These tests use the kwctl cli provided by the Kubewarden project to load and execute the policy.

The e2e tests are implemented using bats: the Bash Automated Testing System.

The end-to-end tests are defined inside of the e2e.bats file and can be run via this commmand:

make e2e-tests

The tests look for a policy.wasm file that is generated via:

make release

Automation

This project contains the following GitHub Actions:

• e2e-tests: this action builds the WebAssembly policy, installs the bats utility and then runs the end-to-end test
• unit-tests: this action runs the Go unit tests
• release: this action builds the WebAssembly policy and pushes it to a user defined OCI registry (ghcr is a perfect candidate)