Secret detection tools for container images
Use tools like ggshield (open source with free option), Gitleaks (open source), or TruffleHog (open source) to detect secrets accidentally committed in container images.
OWASP Cheat Sheets · all subjects
architecture
161 notes in this subject, read out of this brain and free to use. This is page 2 of 3.
Kubernetes misconfiguration detection tools
Use tools like kubeaudit, kubesec.io, or kube-bench to detect misconfigurations in Kubernetes deployments.
Docker daemon default logging level is info
The Docker daemon is configured with a default logging level of info, which can be verified in /etc/docker/daemon.json by checking the log-level key. If not present, info is the default. A log level of info and above captures all logs except debug logs.
Do not run Docker daemon at debug log level
Set an appropriate log level on the Docker daemon. A base log level of info and above captures necessary logs. Do not run the docker daemon at debug log level unless specifically required, as it increases log verbosity and may expose sensitive information.
Rootless mode runs Docker daemon as unprivileged user
In rootless mode, the Docker daemon and containers run as an unprivileged user. If an attacker breaks out of the container, they will not have root privileges on the host, substantially limiting the attack surface. This differs from userns-remap mode where the daemon still operates with root privileges.
Rootless mode does not require root for installation
Docker rootless mode installation does not require root privileges, provided prerequisites are met. Refer to Docker documentation for prerequisites and installation instructions.
Evaluate security posture before enabling rootless mode
Consider specific requirements and security posture of your environment before enabling rootless mode. For environments where security is paramount and rootless mode limitations do not interfere with operational requirements, it is strongly recommended. Alternatively, consider Podman as an alternative to Docker.
Docker Secrets for managing sensitive data
Use Docker Secrets to securely store and manage sensitive data such as passwords, tokens, and SSH keys. This prevents exposure of sensitive data in container images or runtime commands. Example: docker secret create my_secret /path/to/super-secret-data.txt, then docker service create --name web --secret my_secret nginx:latest.
Docker Compose secrets configuration
In Docker Compose, define secrets in the top-level secrets section and reference them in services. Example: version: "3.8", secrets: my_secret: file: ./super-secret-data.txt, services: web: image: nginx:latest, secrets: [my_secret].
Thick client database connections must use API intermediary
When an application is running on an untrusted system (such as a thick-client), it should always connect to the backend database through an API that can enforce appropriate access control and restrictions. Direct connections should never be made from a thick client to the backend database.
Database application hardening requirements
Apply these principles to any database application and platform: install any required security updates and patches; configure the database services to run under a low privileged user account; remove any default accounts and databases; store transaction logs on a separate disk from the main database files; and configure a regular backup of the database with appropriate permissions and ideally encrypted.
MySQL and MariaDB hardening steps
Run the mysql_secure_installation script to remove the default databases and accounts. Disable the FILE privilege for all users to prevent them reading or writing files.
Database server operating system hardening
The database server's underlying operating system should be hardened by basing it on a secure baseline such as the CIS Benchmarks or the Microsoft Security Baselines.
Microsoft SQL Server hardening steps
Disable xp_cmdshell, xp_dirtree, and other stored procedures that are not required. Disable Common Language Runtime (CLR) execution. Disable the SQL Browser service. Disable Mixed Mode Authentication unless it is required. Ensure that the sample Northwind and AdventureWorks databases have been removed.
Database backend isolation strategies
The application's backend database should be isolated from other servers and only connect with as few hosts as possible. Key isolation strategies include: disabling network (TCP) access and requiring all access over a local socket file or named pipe; configuring the database to only bind on localhost; restricting access to the network port to specific hosts with firewall rules; placing the database server on a dedicated internal network segment isolated from the application server; and protecting any web-based management tools (e.g., phpMyAdmin, pgAdmin) with authentication, HTTPS, and network restrictions.
Drone companion computer security
Most drone controllers use two sets of computers: the main chip that performs PID control and handles motors, and an additional SoC (called the companion computer) to manage peripherals like cameras and LiDARs and send telemetry data. Open ports like SSH and FTP can be exploited if not securely configured.
Drone attack vectors summary table
The OWASP Drone Security Cheat Sheet provides a comprehensive attack vector table with columns for: Attack Type, Nature (Infection/Exploitation/Information gathering/Interception/Cracking/Jamming), Targets (Privacy, Data Confidentiality, Integrity, Accessibility, Authentication), and Security Measures (Cryptographic and Non-Cryptographic). Attack types include: Malware, BackDoor Access, Social Engineering, Baiting, Injection/Modification, Fabrication, Reconnaissance, Scanning, Three-Way Handshake, Eavesdropping, Traffic Analysis, Man-in-the-Middle, Password Breaking, Wi-Fi Aircrack, Wi-Fi Jamming, De-Authentication, Replay, Buffer Overflow, Denial of Service, ARP Cache Poison, Ping-of-Death, and GPS Spoofing.
Drone system architecture: UmA, GCS, CDL
A typical drone system consists of three main components: the Unmanned Aircraft (UmA) which is the physical drone including sensors and onboard systems; the Ground Control Station (GCS) which is the interface used to control and monitor drone operations; and the Communication Data-Link (CDL) which is the network connection between the drone and the GCS.
Data encryption for legacy applications
Confirm that, wherever possible, data handled by legacy applications is both encrypted at rest (when stored in a database) and in transit. In some circumstances legacy applications might be restricted to the use of older network protocols that only support transmission of data in plain text. In this case it is especially important to apply the most restrictive network access controls possible to the application, which could necessitate temporary or permanent air-gapping (functional isolation) of the application.
Intermediary service pattern for legacy applications
In some circumstances it may be possible to restrict almost all users from directly accessing the legacy application by developing an intermediary service, such as a separate set of APIs, that handles essential movement of data into and out of the legacy application without end users having any requirement to interact directly with the legacy application.
Port management for legacy applications
Close any ports on hosts used to run legacy applications that are not strictly needed for the application to perform only the tasks required of it by the organization. Access to certain ports may also be restricted using firewall or application firewall rules to lock down server infrastructure.
Kubernetes-native security controls for network segmentation
Use Kubernetes network policies to enforce network segmentation instead of third-party proxies or shims. Native Kubernetes controls should be leveraged to enforce security policies and reduce operational risk.
Node components: kubelet, kube-proxy, container runtime
Node components run on every node and maintain running pods and provide the Kubernetes runtime environment. kubelet is an agent that runs on each node and ensures containers are running in a Pod. kube-proxy is a network proxy running on each node implementing the Kubernetes Service concept. The container runtime is the software responsible for running containers.
etcd access control requires TLS client certificates and network isolation
etcd is a critical component storing cluster state and secrets. Write access to etcd is equivalent to gaining root on the entire cluster; read access can be used to escalate privileges. Administrators must use strong credentials such as mutual TLS client certificates between API servers and etcd, and should isolate etcd behind a firewall that only API servers may access. Allowing other components full keyspace access to primary etcd is equivalent to granting cluster-admin. Use separate etcd instances or etcd ACLs to restrict read and write access to a subset of the keyspace.
Namespace flag and context configuration in kubectl
To set the namespace for a current kubectl request, use the --namespace flag. Examples: kubectl run nginx --image=nginx --namespace=<namespace-name> or kubectl get pods --namespace=<namespace-name>. To permanently set namespace preference for all subsequent kubectl commands in a context, use: kubectl config set-context --current --namespace=<namespace-name>. Validate with: kubectl config view --minify | grep namespace:
Service mesh advantages for Kubernetes security
Service mesh provides: Observability through tracing and telemetry metrics for understanding systems and root cause analysis; Specialized security features identifying compromising traffic and securing services with mTLS, ingress and egress control; Ability to secure microservices with mutual TLS (mTLS) encrypting traffic between services automatically; Ingress and egress control monitoring and addressing compromising traffic; Operational Control for security and platform teams to enforce access controls while allowing developer customization; Ability to manage Role-Based Access Control restricting privileged users to least privileges and ensuring default-deny access.
Service mesh disadvantages for Kubernetes
Service mesh also introduces challenges: Adds a new layer of complexity when proxies, sidecars, and other components are introduced to sophisticated environments, dramatically increasing development and operations complexity; Additional expertise required as operators must become experts in both mesh technology (e.g. Istio) and orchestrators (e.g. Kubernetes); Infrastructure can be slowed because service mesh is invasive and intricate technology; Requires adoption of yet another platform as service meshes are invasive and force developers and operators to adapt to highly opinionated platforms and conform to their rules.
Kubernetes NetworkPolicy example for pod-to-pod communication control
NetworkPolicy controls network access between pods. Example: restricting backend pods to only accept inbound access from frontend pods on port 80 TCP. Kubernetes allows every pod to contact every other pod by default; network segmentation ensures containers only communicate with approved containers and prevents lateral movement. Network policies are applied via namespace and can use pod selectors and port specifications.
Container sandboxing technologies: Kata Containers, gVisor, Firecracker
Container sandboxing adds isolation layers beyond Cgroups and namespaces for multi-tenant and untrusted clusters to prevent container breakout and kernel exploits. Kata Containers uses stripped-down VMs minimizing resource footprint while maximizing performance. gVisor is a lightweight Go-based kernel sitting between container and host kernel, supporting approximately 70% of Linux system calls while only using about 20 system calls to host kernel. Firecracker is a super lightweight VM running in user space, locked down by seccomp, cgroup, and namespace policies.
Control Plane components: kube-apiserver, etcd, kube-scheduler, kube-controller-manager, cloud-controller-manager
The Kubernetes control plane consists of five key components. kube-apiserver exposes the Kubernetes API and serves as the front end for the control plane. etcd is a consistent, highly-available key-value store used as Kubernetes' backing store for all cluster data. kube-scheduler watches for newly created Pods with no assigned node and selects a node for them to run on. kube-controller-manager runs controller processes that logically are separate but compiled into a single binary and run in a single process. cloud-controller-manager links the cluster into the cloud provider's API and separates components that interact with the cloud platform from those that interact only with the cluster.
Prevent unwanted kernel module loading via blacklist configuration
Linux kernel automatically loads kernel modules from disk when needed (hardware attachment, filesystem mount), creating attack surface. Unprivileged processes can cause network-related kernel modules to load by creating appropriate sockets. Block modules by uninstalling them or adding rules to /etc/modprobe.d/kubernetes-blacklist.conf to blacklist specific modules. Use Linux Security Modules like SELinux to completely deny module_request permission to containers, preventing kernel module loading for containers. Pods can still use pre-loaded or manually-loaded modules.
Open Policy Agent (OPA) for centralized policy management in Kubernetes
OPA is an OSS project (now CNCF incubating) started in 2016 to unify policy enforcement across technologies. OPA can enforce policies on Kubernetes platforms and create unified method of enforcing security policy in the stack. Unlike RBAC and Pod Security Policies which only apply within cluster, OPA can integrate with APIs, Linux SSH daemon, object stores like Ceph, and accept any valid JSON data as request attributes. OPA policies and decisions do not follow specific format, allowing flexibility in return values (True/False JSON, number, string, complex data object).
OPA use cases: application authorization, Kubernetes admission control, service mesh authorization
OPA can provide application authorization eliminating need for homegrown solutions with declarative policy language for rules like 'Alice can write to this repository' with tools for integration and end-user policy creation. OPA for Kubernetes admission control integrates into API server with authority to reject resources violating policies, addressing security concerns by enforcing policies on image trust, root restrictions, encryption, and limiting internet access while allowing policy exposure early in development. OPA for service mesh authorization regulates service mesh use and can control microservice APIs with policies limiting lateral movement within microservice architectures.
Kubernetes events command retrieval
Use the kubectl get events -n <namespace> command to retrieve all events within a specific namespace. The output columns are: NAMESPACE, LAST SEEN, TYPE, REASON, OBJECT, and MESSAGE. Events indicate Kubernetes resource state changes, errors such as exceeded resource quota or pending pods, and informational messages.
Kubernetes pod events inspection
Use the kubectl describe pod <pod-name> command to show the latest events for a specific Kubernetes resource. The output displays a table with columns: Type, Reason, Age, From, and Message.
systemd logs retrieval command
Use the journalctl -u command to retrieve systemd logs from the host machine. This is necessary for understanding logs from services running at the operating system level in Kubernetes clusters.
Container log rotation in Kubernetes
When a container is terminated or restarted, kubelet stores logs on the node. Kubernetes implements a log rotation mechanism to prevent these files from consuming all host storage. When a container is evicted from the node, all containers with corresponding log files are evicted.
Cluster logging components storage locations
Systemd services in Kubernetes clusters write logs to journald. Components running in containers write logs to the /var/log directory, unless the container engine has been configured to stream logs differently.
Perform sanitization on all event data to prevent log injection
Perform sanitization on all event data to prevent log injection attacks. Remove or escape carriage return (CR), line feed (LF) and delimiter characters. Optionally remove sensitive data during sanitization.
Encode event data correctly for the output format
Encode all event data correctly for the output (logged) format to prevent encoding-based attacks.
Apply SQL injection cheat sheet when writing logs to databases
If writing event logs to databases, read, understand, and apply the SQL injection cheat sheet to prevent SQL injection vulnerabilities in logging code.
Ensure logging failures do not prevent application operation
Ensure failures in the logging processes/systems do not prevent the application from otherwise running or allow information leakage. The application must continue to function even if logging fails.
Synchronize time across all servers and devices
Synchronize time across all servers and devices that generate log events. When this is not always possible (such as for applications running on devices under another party's control like mobile phones or remote customer workstations), attempt to measure the time offset or record a confidence level in the event timestamp.
Log storage: file system considerations
When using the file system for event log storage: use a separate partition than those used by the operating system, other application files and user generated content; apply strict permissions concerning which users can access the directories and files within the directories; logs should not be exposed in web-accessible locations, and if exposed, should have restricted access and be configured with a plain text MIME type (not HTML).
Log storage: database considerations
When using a database for event log storage: use a separate database account that is only used for writing log data and which has very restrictive database, table, function and command permissions.
Use standard log formats and secure transmission protocols
Use standard formats over secure protocols to record and send event data or log files to other systems. Examples include Common Log File System (CLFS) or Common Event Format (CEF) over syslog. Standard formats facilitate integration with centralized logging services.
Separate extended event information into separate files/tables
Consider separate files or tables for extended event information such as error stack traces or a record of HTTP request and response headers and bodies.
Tamper detection for stored logs
Build in tamper detection so you know if a log record has been modified or deleted. This is a protection mechanism against integrity attacks on logs.
Log data protection: read-only storage
Store or copy log data to read-only media as soon as possible to protect against tampering.
Log access control and monitoring
All access to logs must be recorded and monitored and may need prior approval. The privileges to read log data should be restricted and reviewed periodically.
Log transmission security over untrusted networks
If log data is sent over untrusted networks (for collection, dispatch elsewhere, analysis, or reporting), use a secure transmission protocol. Consider whether the origin of the event data needs to be verified.
Due diligence before sending logs to third parties
Perform due diligence checks (regulatory and security) before sending event data to third parties.
Incorporate application logging into centralized log management systems
Incorporate the application logging into any existing log management systems/infrastructure such as centralized logging and analysis systems (SIEM, SEM). Ensure event information is available to appropriate teams and enable alerting to signal responsible teams about more serious events immediately.
Share event information with other detection systems
Share relevant event information with other detection systems, related organizations and centralized intelligence gathering/sharing systems.
Log data retention periods
Log data, temporary debug logs, and backups/copies/extractions must not be destroyed before the duration of the required data retention period, and must not be kept beyond this time. Legal, regulatory and contractual obligations may impact on these periods.
Event attributes: who (user identity and source)
Each log entry must include the following identity attributes for human or machine users: source address (user's device/machine identifier, user's IP address, cell/RF tower ID, mobile telephone number); user identity if authenticated or otherwise known (user database table primary key-value, username, license number).
Always log application errors and system events
Application errors and system events must always be logged. These include syntax and runtime errors, connectivity problems, performance issues, third party service error messages, file system errors, file upload virus detection, and configuration changes.
Always log application and system start-ups, shut-downs, and initialization
Application and related systems start-ups and shut-downs must be logged, as well as logging initialization events including starting, stopping or pausing.
Always log higher-risk functionality usage
The following higher-risk functionality must always be logged: user administration actions such as addition or deletion of users, changes to privileges, assigning users to tokens, adding or deleting tokens; use of systems administrative privileges or access by application administrators including all actions by those users; use of default or shared accounts or break-glass accounts; access to sensitive data such as payment cardholder data; encryption activities such as use or rotation of cryptographic keys; creation and deletion of system-level objects; data import and export including screen-based reports; submission and processing of user-generated content especially file uploads; deserialization failures; network connections and associated failures such as backend TLS failures including certificate validation failures, or requests with an unexpected HTTP verb.
Always log legal and opt-in events
Legal and other opt-in events must always be logged. Examples include permissions for mobile phone capabilities, terms of use, terms & conditions, personal data usage consent, and permission to receive marketing communications.