docs: safeguard improvements

docs/user-guide/safeguards/enforce-job-ttl.md

@@ -6,10 +6,14 @@ tags: []
 
 # Improve platform stability: Job TTL
 
+!!!important
+
+    - This safeguard is enabled by default and will mutate violations. As a result, resources that violate this policy will be modified with a default config so that it does follow the policy.
+
 In Kubernetes, Jobs that are not managed by a higher-level resource such as a Cronjob, will most likely not get cleaned up automatically as Jobs do not have a default time-to-live, TTL, configured.
 In worst case the number of finished jobs could accumulate to such a volume that it might impact the stability of the Kubernetes cluster.
 
-However, by default in Compliant Kubernetes, Jobs that do not explicitly set a TTL (`spec.ttlSecondsAfterFinished`) automatically get a TTL of 7 days.
+However, by default in Compliant Kubernetes, there is a policy that demands Jobs to have a TTL. Jobs that do not explicitly set a TTL (`spec.ttlSecondsAfterFinished`) will automatically get a TTL of 7 days.
 
 ## Further Reading
 

docs/user-guide/safeguards/enforce-minimum-replicas.md

@@ -6,6 +6,10 @@ tags: []
 
 # Avoid Downtime with Replicas
 
+!!!important
+
+    - This safeguard is enabled by default and will warn on violations. As a result, resources that violate this policy will generate warning messages, but will still be created.
+
 Compliant Kubernetes by default recommends a minimum of 2 replicas for Deployments and StatefulSets.
 
 Therefore a warning will be issued when you add or update a Deployment or StatefulSet where the number of replicas is less than 2.

docs/user-guide/safeguards/enforce-networkpolicies.md

@@ -19,8 +19,7 @@ tags:
 
 !!!important
 
-    - This safeguard is enabled by default with the enforcement action `deny` since [Compliant Kubernetes apps v0.19.0](../../release-notes/ck8s.md#v0190). As a result, resources that violate this policy will not be created.
-    - The default enforcement action for this safeguard has been changed to `warn` instead of `deny` since [Compliant Kubernetes apps v0.29.0](../../release-notes/ck8s.md#v0290). As a result, resources that violate this policy will generate warning messages, but will still be created.
+    - This safeguard is enabled by default and will warn on violations. As a result, resources that violate this policy will generate warning messages, but will still be created.
 
 NetworkPolicies are useful in two cases: segregating tenants hosted in the same environment and further segregating application components. Both help you achieve better data protection.
 

docs/user-guide/safeguards/enforce-no-latest-tag.md

@@ -19,7 +19,7 @@ tags:
 
 !!!important
 
-    This safeguard is enabled by default with the enforcement action `deny` since [Compliant Kubernetes apps v0.29.0](../../release-notes/ck8s.md#v0290). As a result, resources that violate this policy will not be created.
+    This safeguard is enabled by default and will deny violations. As a result, resources that violate this policy will not be created.
 
 Using the `:latest` tag can lead to inconsistent deployments, where it is difficult to rollback. In Compliant Kubernetes we suggest using explicit tags for your container images. This way you know that image version `v1.0.0` will be deployed if you are using the `:v1.0.0` tag.
 
@@ -33,9 +33,11 @@ Error from server ([container-image-must-not-have-disallowed-tags] container <ex
 
 This means that you are not allowed to use the `:latest` tag on your images. If no tag is specified, Kubernetes assumes `:latest`, but that does not mean that the most recent version of the image will actually be used. `:latest` is just a tag and is not dynamically updated to the most recent version of the image. It also becomes difficult to track which version of the image was used if you were to do a rollback.
 
-To fix this, you have the following options:
+To fix this, you have to start specifying tags for your images i.e. `v1.0.0`.
 
-- Use a meaningful tag for your images i.e. `v1.0.0`.
+We recommend that you treat all tags as immutable, i.e. you don't use tags like `dev` or `prod` that you intend to continue to push tags to. Do this by always creating a new tag when you push a new image, you can include some versioning or a hash to make the tag unique. E.g. `prod-v1.2.3` or `dev-f6451806e5b6`. If you do not treat tags as immutable, then you get the same risk of having inconsistent deployments.
+
+It is possible to add more tags that will be denied. Perhaps you want to deny images with `dev` tags in your production environment. If you want to add more tags that should be denied, then contact your administrator.
 
 If your administrator has not enforced this policy yet, you can view current violations of the policy by running:
 

docs/user-guide/safeguards/enforce-no-load-balancer-service.md

@@ -6,13 +6,19 @@ tags: []
 
 # Avoid deploying a Load Balancer Service on unsupported cloud providers
 
+!!!important
+
+    This safeguard is enabled by default for some infrastructure providers and will deny violations. As a result, on those specific infrastructure providers resources that violate this policy will not be created.
+
 Some infrastructure providers do not support `Service` of `type: LoadBalancer`, e.g. because the load-balancers don't integrate with Kubernetes.
-In such cases your administrator may deploy a policy to prevent such Services from being deployed.
+In such cases your administrator will deploy a policy to prevent such Services from being deployed.
 
 When attempting to apply a `Service` with `type: LoadBalancer` anyway, the following error message would be returned:
 
-> Creation of LoadBalancer Service is not supported.
-> Contact your platform administrator for questions about Load Balancers.
+```console
+Creation of LoadBalancer Service is not supported.
+Contact your platform administrator for questions about Load Balancers.
+```
 
 ```yaml
 apiVersion: v1

docs/user-guide/safeguards/enforce-no-root.md

@@ -18,6 +18,10 @@ tags:
     - A.12.6.1 Management of Technical Vulnerabilities
     - A.14.2.5 Secure System Engineering Principles
 
+!!!important
+
+    This safeguard is enabled by default and will deny violations. As a result, resources that violate this policy will not be created.
+
 Many container runtimes and operating system vulnerabilities need code running as root to become a threat. To minimize this risk, application should only run as root when strictly necessary.
 
 Unfortunately, many Dockerfiles -- and container base images -- today are shipped running as root by default. This makes it easy to slip code running as root into production, exposing data to unnecessary risks.

docs/user-guide/safeguards/enforce-podsecuritypolicies.md

@@ -7,6 +7,10 @@ tags:
 
 # Reduce blast radius: Enforcing restricted privileges
 
+!!!important
+
+    - This group of safeguards are enabled by default and will deny or mutate on violations. As a result, resources that violate this policy will either not be created or they will be mutated to conform to the policy, depending on the type of violation.
+
 This page helps you understand why warnings are emitted when deploying workloads similar to:
 
 ```console
@@ -165,6 +169,10 @@ Certain applications may need more privileges than what is allowed from the rest
 To do so application developers should put together a Pod Security Policy to be evaluated and accepted by the platform administrator, which then can allow access to these privileges in a certain namespace for resources with a certain label.
 The format should be as follows:
 
+!!! elastisys "For Elastisys Managed Services Customers"
+
+    Please file a [service ticket](https://elastisys.atlassian.net/servicedesk/) and we will review and discuss your request for increased privileges. We will try to find a solution that works for you, but there is no guarantee that your request will be approved.
+
 ```yaml
 podSelectorLabels: # Must be provided
   <key>: <value>

docs/user-guide/safeguards/enforce-resources.md

@@ -26,7 +26,7 @@ Note to contributors: Aim for the following format.
 
 !!!important
 
-    This safeguard is enabled by default with the enforcement action `deny` since [Compliant Kubernetes apps v0.19.0](../../release-notes/ck8s.md#v0190). As a result, resources that violate this policy will not be created.
+    This safeguard is enabled by default and will deny violations. As a result, resources that violate this policy will not be created.
 
 ## Problem
 

docs/user-guide/safeguards/enforce-trusted-registries.md

@@ -28,8 +28,7 @@ Note to contributors: Aim for the following format.
 
 !!!important
 
-    - This safeguard is enabled by default with the enforcement action `deny` since [Compliant Kubernetes apps v0.19.0](../../release-notes/ck8s.md#v0190). As a result, resources that violate this policy will not be created.
-    - The default enforcement action for this safeguard has been changed to `warn` instead of `deny` since [Compliant Kubernetes apps v0.29.0](../../release-notes/ck8s.md#v0290). As a result, resources that violate this policy will generate warning messages, but will still be created.
+    - This safeguard is enabled by default and will warn on violations. As a result, resources that violate this policy will generate warning messages, but will still be created.
 
 ## Problem
 

docs/user-guide/safeguards/index.md

@@ -20,6 +20,7 @@ tags:
 We know you care about the security and uptime of your application. But all that effort goes wasted if the platform allows you to make trivial mistakes.
 
 That is why Compliant Kubernetes is built with various safeguards, to allow you to make security and reliability easy for you.
+Please look through the different pages in this Safeguard section to make yourself familiar with what the safeguards expect from your application.
 
 ## Relevant Regulations