In addition to the out-of-the-box security capabilities provides by the Akamai App Platform, it is the responsibility of both platform administrators and team members to ensure their workloads are properly secure and safe from malicious actors.

Best practices for platform administrators

The Akamai App Platform comes with many security capabilities. It is up to the platform administrator to make sure these capabilities are enabled and correctly used. The following checklist can be used to make sure security is implemented to follow best-practices.

1. Install the cloud-firewall-controller for LKE: Using the cloud-firewall-controller ensures that all nodes in the cluster are added to the same Cloud firewall ruleset.
2. Limit access to the cluster API server: Kubernetes API servers should not ordinarily be exposed to the open internet. Use the Control Plane ACL for LKE to only allow access to the API server from trusted IP addresses.
3. Use Object Storage for persistency: Use the Object Storage Wizard in the App Platform to prevent data loss. If container logs contain sensitive data, the bucket used by Loki can be encrypted (at rest) using SSE-C (SSE-S3/SSE-KMS is currently not supported).
4. Enable vulnerability scanning in Harbor: Enable Automatically scan images for vulnerabilities in the Team project settings in Harbor to automatically scan all images on push.
5. Don't disable network policies for Teams: By default, the App Platform enforces the use of network policies (ingress and egress). This means that by default all traffic between Pods in the Team namespace and access to external URLs or IP addresses is forbidden. To allow traffic between Pods or access to external URLs or IP addresses, Teams need to create network policies. Disabling network policies increases risks and is not advised.
6. Enable observability: The App Platform comes with a fully integrated and pre-configured stack of observability applications for Kubernetes. The observability applications (like Prometheus, Grafana and Alertmanager) are disabled by default. It is advised to turn on the observability applications to get insights into resource usage and possible issues.
7. Secure Personally Identifiable Information: By default (during installation), the App Platform will use a self-hosted Keycloak instance as an internal identity provider (IdP). When users are created in the App Platform, these users will be stored in Keycloak. The user data in Keycloak is NOT encrypted. When Personally Identifiable Information (PII) needs to be encrypted because of compliance regulations, it is advised to enable disk encryption or configure the App Platform to use an external IdP:
   • Enable disk encryption on all nodes: Disk encryption ensures that your data stored on compute instances is secured. In addition to Akamai's information security compliance with standards such as SOC 2, disk encryption provides further protections by keeping data encrypted, even if the disk is removed, decommissioned, or disposed of. See the Local Disk Encryption documentation for more information.
   • Use an external Identity Provider: Configure the App Platform to use an OIDC setup through Azure Entra ID.
8. Configure Keycloak to use 2 factor authentication (MFA): When no external IdP is used, it is advised to configure the otomi realm to force users to use a MFA app like Google Authenticator, Microsoft Authenticator or Free OTP to use one time passwords (OTP). See Keyclock documentation for instructions.

Best practices for developers and teams

Here is a list of security recommendations that all teams using the App Platform should consider implementing:

1. Use Sealed Secrets to secure sensitive data and use a secretKeyRef to map an environment variable to the secret data.

2. Drop ALL or specific capabilities in the Pod or container SecurityContext to ensure all (unused) capabilities are disabled.

3. Make sure containers are running with a read-only root file system by setting the readOnlyRootFilesystem to true in the Pod or container SecurityContext.

4. Prevent pods from sharing the host’s IPC or network namespace by setting the hostNetwork parameter to false.

5. Avoid running containers in privileged mode by setting the allowPrivilegeEscalation parameter to false in the Pod or container SecurityContext.

6. Identify and mitigate threats in running containers. See the Detect threats in running containers hands-on lab for more information.

7. Scan running container for vulnerabilities. See the Scan your running containers for vulnerabilities hands-on lab for more information.

8. Scan images pushed to the Team's private container registry in Harbor for vulnerabilities. See the Scan your images for vulnerabilities hands-on lab for more information.