Advanced Cluster Security (ACS) Admission Controllers

When you go to the {acs_url}/main/policy-management/policies["Policy Management" View^,window="acs"] (also under "Platform Configuration") you will see a lot of policies, also with several "Lifecycle" stages.

For the Admission Controller, only the "Deploy" lifecycle stage is of relevance - it will evaluate the policy (if active and properly defined) on deployment and act on it (Inform or Inform&Enforce = Block the Deployment).

If you filter by the {acs_url}/main/policy-management/policies?s%5BLifecycle%20Stage%5D=DEPLOY["DEPLOY lifecycle"^,window=acs], you can see all system policies that have been defined for the deployment (i.e. can be enforced by the ACS Admission Controller)

As you can see, ACS focuses more on the vulnerability side of security, where the Sigstore Admission Controller focuses on the integrity and attestations.

Checking for valid signatures is where they have an overlap, so let’s create policies that

We can add more than one key to validate images - so images from multiple signature sources can be validated with the same signature integration.
We can also create multiple integrations with a single key each.

Another option (can also be used in the same integration) is to verify "keylessly signed" images by providing the RHTAS endpoints.

If we want to verify proof-of-inclusion with the Rekor transparency log (proof that the signing event has happened and has been recorded), we can configure that also - or disable, but that would be less secure.

With that said, let’s create a new Integration.

1) {acs_url}/main/integrations/signatureIntegrations/signature[Start here^,window="acs"] and click on "New Integration"

2) Give it a name, such as "Cosign Keys"

3) We have prepared a script that prints all the configuration data you need. Go to the terminal here and run this script:

You will get a printout similar to this one (yours will be different)

Now copy the values over - it will look similar to this (your values will be different) - then click "Save"

When you {acs_url}/main/integrations/signatureIntegrations/signature[click here^,window="acs"], you should now have a new "Signature Integration" with our keys that Tekton Chains (and we) used to sign images.

Ok, let’s see what it does when we try to deploy our unsigned image to our student-acs-test namespace:

In the terminal run the following code again:

Ok, that worked, as expected (we’re just at "Inform" level) - but where is our warning?

It’s in the {acs_url}/main/violations?violationState=ACTIVE&filteredWorkflowView=Applications%20view[Violations Dashboard^,window="acs"] and would have triggered a notification to our Notifier of choice (if we had defined any):

So, let’s see what happens if we set it to "enforce":

From the {acs_url}/main/policy-management/policies["Policy Management" View^,window="acs"], use the menu on the right (as shown above) or open it and use the "Actions Menu"

You can click through via "Next, Next, Next,…​" or you can directly go to "Actions"

When you switch to "Inform & Enforce", you can tailor on which lifecycle stages the enforcement will actually happen. Since we defined this policy to only support the "Deploy" lifecycle, we can only enable "Enforce on Deploy". If we had a policy applicable to multiple stages, we could fine-tune where enforcement should happen.

Click "Next", then "Save"

Now, let’s try again in our terminal:

Huh? All good? 🤔

ok, so let’s delete it first and then try again:

A-ha! 💡 Now the Admission Controller enforces the policy and blocks the deployment - anf we had provided some meaningful Description, a rationale for the policy and common remediation strategies, these would also be shown here (and would appear in logs, etc.)

In addition to that, we can also find the Violation in the {acs_url}/main/violations?violationState=ATTEMPTED&filteredWorkflowView=Applications%20view["Attempted"^,window="acs"] view in ACS.

OK, now we know our policy blocks an unsigned image - but would it allow an image singed with the correct key and inclusion proof in the Rekor transparency database?

Let’s try:

As expected, that worked ✅

Verifying image signatures is something that the Sigstore Admission Controller can do as well, so let’s add something that Sigstore can’t but ACS excels at: Scanning for vulnerabilities.

So, we’ll create a policy "0-no fixable vulnerabilities" that doesn’t allow any FIXABLE severity:

Since you’ve already learned how to create a policy:

Click on the thumbnails to enlarge:

Note that you have a preview on the "Review" page, so you can directly check if your policy and scope is ok and also which deployments wouldn’t have gone through (since it is not a "Runtime" policy, there’s nothing it can do about it.)

So, let us put this to the test:

Now that we try to deploy this one, you can see it’s being blocked because of the fixable vulnerabilities present: