How to use the Certificate Policy Controller to Identify Risks in Red Hat Advanced Cluster Management for Kubernetes

Overview

The Governance and Risk capabilities of Red Hat Advanced Cluster Management for Kubernetes provide many ways to help your managed clusters adhere to security guidelines that your enterprise has defined. A critical security guideline is how to properly manage certificates. By writing a simple security policy, Red Hat Advanced Cluster Management can assist in hardening the security for all of your clusters with certificate management. Keep reading to see how the certificate policy functionality in Red Hat Advanced Cluster Management for Kubernetes can benefit your enterprise.

What can certificate policies report?

The primary goal of certificate policies in Red Hat Advanced Cluster Management is to alert when a certificate is nearing expiration. There's a lot more that can be done too, and many things to take into account when you set up your policy. First, let's take a look at the different features the policy controller defines in the following table:

For more information on the syntax of the fields view the following links:

• Golang time format
• Golang regular expression syntax

Considering namespaces

An important point to remember is that the policies are namespace-based. A policy can be applied to multiple namespaces by using a pattern similar to the following sample: myapp\* If some namespaces matching your pattern have certificates that you know have very different characteristics, you may want to define a second policy tailored to that namespace. The namespace selector can be changed to select only the namespaces that you want to match for a given policy.

Another important point to realize is that there could be many certificates that have different characteristics within a single namespace. In this case, you have to make sure your controls are not going to alert on false positives based on the different durations, or naming conventions used in that namespace. While this could be seen as a limitation, it is beneficial because the policy is always searching a namespace for any certificates to make sure none are missed in the search for policy violations.

Do not use the certificate policy controller as a replacement for your certificate management tools. The certificate policy controller cannot reissue certificates that are expiring because it does not know how your certificates were issued. The goal is to alert on shortcomings of your certificate management, so any failures of your processes that reissue certificates are detected prior to the expiration date of the certificate. This means you have to coordinate your certificate management and your certificate policies. Take a look at the next section to see details on how this can work.

Simple certificate management scenario

There are three main decisions to make when you create a new certificate policy.

1. What characteristics do my certificates have?
2. What namespaces are my certificates located in?
3. What policies are in place for certificate management in my organization?

The simplest case is one certificate located in a well known namespace. Suppose the following commands are run to create your certificate:

openssl req -x509 -newkey rsa:4096 -nodes -keyout key.pem -out cert.pem -days 100

kubectl create secret -n default tls test-cert --key=key.pem --cert=cert.pem

This certificate exists in a default namespace and is valid for 100 days from the time it is created. We've just answered the first two questions that were previously asked. The third question requires knowing how you intend to replace the certificate prior to expiration. Is the certificate replacement an automated process, or is it manual? Let's assume you wrote a cron job that runs daily and reissues the certificate if it expires within 25 days. In this case, you might want to create the policy so it alerts if the certificate is expiring in less than 20 days. This gives the cron job a few days to attempt to renew the certificate so you are only alerted if that procedure fails, while at the same time allowing you to have plenty of time to reissue the certificate when the policy alerts you of this condition.

Sample policies

The following examples are samples that can help you think through how to implement certificate policies in your clusters:

Example 1: Certificate Expiration

If you obtain a trusted certificate today, that certificate has a lifetime that is expected to be less than 398 days. For more information, see the Apple article: About upcoming limits on trusted certificates.

While that seems like a long time, the certificate signing community continues to decrease lifetimes of trusted certificates in an effort to increase security in the applications that we use every day. You can use the certificate policy controller to govern the certificates that application developers are providing.

Here's a certificate expiration sample policy for applications that are installed in namespaces starting with app.

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-govern-certificates
  namespace: policies
  annotations:
    policy.open-cluster-management.io/categories: SC System and Communications Protection
    policy.open-cluster-management.io/controls: SC-8 Transmission Confidentiality and Integrity
    policy.open-cluster-management.io/standards: NIST 800-53
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: CertificatePolicy
        metadata:
          name: policy-govern-certificates-example
        spec:
          maximumCADuration: 87600h
          maximumDuration: 9528h
          minimumDuration: 600h
          namespaceSelector:
            include:
              - app*
          remediationAction: inform
          severity: low
  remediationAction: inform

The previous policy sample uses the following settings for the certificate policy:

• The maximumDuration is set to 9528h which is 397 days. This is the current limit for newly signed certificates that are publicly trusted.
• The maximumCADuration is set to 87600h which is 10 years. CA certificates do not have the same lifetime limitation that signed certificates have, so a different threshold is most likely required if your environment contains CA certificates.
• The minimumDuration is set to 600h which is 25 days. The cert-manager defaults to 90 day certificates that refresh when they have 30 days left. Use this to catch any users that select shorter renew times which could risk an outage.
• The minimumCADuration is not set, so it uses the same 25 day threshold.

Example 2: Certificate DNS name checking

As another example, let's consider a scenario where you do not want applications to use any wildcard certificates. How could you enforce this requirement using the certificate policy controller? Fortunately, the disallowedSANPattern parameter makes this a straightforward change. Here's a sample policy to accomplish this requirement:

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-certificatepolicy-1
  namespace: fraud-management
  annotations:
    policy.open-cluster-management.io/categories: PR.DS Data Security
    policy.open-cluster-management.io/controls: PR.DS-2 Data-in-transit
    policy.open-cluster-management.io/standards: 'NIST, NIST-CSF'
  spec:
    disabled: false
    policy-templates:
      - objectDefinition:
          apiVersion: policy.open-cluster-management.io/v1
          kind: CertificatePolicy
          metadata:
            name: policy-certificatepolicy-1-example
          spec:
            disallowedSANPattern: '[\*]'
            minimumDuration: 12h
            namespaceSelector:
              include:
                - my*
    remediationAction: inform
    severity: low
  remediationAction: inform

Note the following settings in the previous policy sample:

• The minimumDuration is set to 12h. This is a deliberately a very low value that is used to shift the focus of this policy away from expiration and towards other settings. The certificate policy controller checks for certificate expiration. If you want to disable expiration checks, you must set the minimumDuration to a value that is lower than you expect any of your certificates to ever be. In this case, the value selected is 12h since I am expecting other policies to handle any certificate management for the namespaces targeted with this policy.
• Set disallowedSANPattern to the value, '[\*]', to detect wildcards in certificates. Make sure you include the single quotes around the regular expression.

Another important aspect of policy creation is making sure you are specifying namespaces in the selectors properly. The samples mentioned earlier are selecting namespaces that begin with app and my respectively. Note, that if these two samples make sense to be part of one policy, you can define them both in one policy. Here's a sample of the two samples mentioned before, combined into a single policy:

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: policy-govern-certificates
  namespace: policies
  annotations:
    policy.open-cluster-management.io/categories: SC System and Communications Protection
    policy.open-cluster-management.io/controls: SC-8 Transmission Confidentiality and Integrity
    policy.open-cluster-management.io/standards: NIST 800-53
spec:
  disabled: false
  policy-templates:
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: CertificatePolicy
        metadata:
          name: policy-govern-certificates-example
        spec:
          maximumCADuration: 87600h
          maximumDuration: 9528h
          minimumDuration: 600h
          namespaceSelector:
            include:
              - app*
          remediationAction: inform
          severity: low
    - objectDefinition:
        apiVersion: policy.open-cluster-management.io/v1
        kind: CertificatePolicy
        metadata:
          name: policy-certificatepolicy-1-example
        spec:
          disallowedSANPattern: '[\*]'
          minimumDuration: 12h
          namespaceSelector:
            include:
              - my*
          remediationAction: inform
          severity: low
  remediationAction: inform

Use this flexibility to apply certificate policies to namespaces that you want to be treated differently.

Conclusion

The certificate policy controller can be a valuable tool to help make sure your clusters are managing certificates correctly. It's important to understand how this tool works, so policies are set up to make sure alerts are sent when needed. If this guide helps you write policies that are useful and you believe others would benefit from them, consider donating the policy to the open source repository, policy-collection.

For more details on contributing policies, see the blog Contributing and deploying community policies with Red Hat Advanced Cluster Management and GitOps. For more details on creating certificate policies in Red Hat Advanced Cluster Management, see the product documentation.