Kubernetes Security: Reviewing Integrations, Encrypting Secrets, and Staying Updated

lifetimes where possible. If you use service-account tokens in external integrations, plan to rotate those tokens frequently. For example, once the bootstrap phase is complete, a bootstrap token used for setting up nodes should be revoked or its authorization removed. ### Review third party integrations before enabling them Many third party integrations to Kubernetes may alter the security profile of your cluster. When enabling an integration, always review the permissions that an extension requests before granting it access. For example, many security integrations may request access to view all secrets on your cluster which is effectively making that component a cluster admin. When in doubt, restrict the integration to functioning in a single namespace if possible. Components that create pods may also be unexpectedly powerful if they can do so inside namespaces like the `kube-system` namespace, because those pods can gain access to service account secrets or run with elevated permissions if those service accounts are granted access to permissive [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/). If you use [Pod Security admission](/docs/concepts/security/pod-security-admission/) and allow any component to create Pods within a namespace that permits privileged Pods, those Pods may be able to escape their containers and use this widened access to elevate their privileges. You should not allow untrusted components to create Pods in any system namespace (those with names that start with `kube-`) nor in any namespace where that access grant allows the possibility of privilege escalation. ### Encrypt secrets at rest In general, the etcd database will contain any information accessible via the Kubernetes API and may grant an attacker significant visibility into the state of your cluster. Always encrypt your backups using a well reviewed backup and encryption solution, and consider using full disk encryption where possible. Kubernetes supports optional [encryption at rest](/docs/tasks/administer-cluster/encrypt-data/) for information in the Kubernetes API. This lets you ensure that when Kubernetes stores data for objects (for example, `Secret` or `ConfigMap` objects), the API server writes an encrypted representation of the object. That encryption means that even someone who has access to etcd backup data is unable to view the content of those objects. In Kubernetes {{< skew currentVersion >}} you can also encrypt custom resources; encryption-at-rest for extension APIs defined in CustomResourceDefinitions was added to Kubernetes as part of the v1.26 release. ### Receiving alerts for security updates and reporting vulnerabilities Join the [kubernetes-announce](https://groups.google.com/forum/#!forum/kubernetes-announce) group for emails about security announcements. See the [security reporting](/docs/reference/issues-security/security/) page for more on how to report vulnerabilities. ## What's next - [Security Checklist](/docs/concepts/security/security-checklist/) for additional information on Kubernetes security guidance. - [Seccomp Node Reference](/docs/reference/node/seccomp/)

This section emphasizes the importance of rotating service account tokens, thoroughly reviewing third-party integrations and restricting their access, especially in system namespaces, to prevent privilege escalation. It also highlights the necessity of encrypting secrets at rest using Kubernetes' built-in encryption features and ensuring encrypted backups of the etcd database. Finally, it recommends staying informed about security updates by joining the kubernetes-announce group and following the security reporting guidelines.