The etc database is encrypted at rest and access is granted using RBAC (protections described above). For use by the deployments themselves, secret data is stored in Kubernetes secrets which in turn is stored by the Kubernetes API in etcd.Our services use dedicated service accounts (in GCP) or IAM accounts (in AWS) to communicate with these cloud services.Most of these service accounts don't allow any direct access to the Kubernetes API and of those that do, most of that access is read-only. Inside of our Kubernetes clusters, each deployment uses its own service account credentials which only grants it access to certain allowed functions.All access to production infrastructure or customer data is monitored.Employees are only granted access to production infrastructure or tooling if their job description requires it.Every employee has individual logins to services (via our corporate GSuite accounts if the service supports it) and they are responsible for creating strong passwords and storing them securely.As a result of this, entire environments can be recreated from scratch if needed.We don't operate any so-called "pet servers" that are managed by hand. All deployments are scripted and reproducible.All configuration that we need to deploy the entire infrastructure is stored in a central code repository.For certain key metrics, we set an alerting threshold so that our on-call team can investigate. We collect detailed application-level and infrastructure-level metrics.We have rate limits in place both in Cloudflare and in our infrastructure to reduce the risk of brute-force attacks.All requests to our infrastructure are routed through Cloudflare's CDN network, which is built to withstand complex and large DDOS attacks.The only application servers exposed to the public Internet are NGINX reverse proxies.The servers running our Kubernetes clusters are exposed publicly but they run the hardened Container-Optimized OS from Google and all administrative access is disabled.We do not allow any privileged access based on IP address. All staff access to the services running inside the infrastructure is authenticated and authorized using corporate Google accounts (which all have multi-factor authentication enabled).Avocode infrastructure in GCP and AWS are both in isolated VPCs.Each staff member uses their own account to log into the infrastructure. We maintain audit logs for all actions performed within GCP and AWS.We use the identity and access management (IAM) tools in both GCP and AWS to only give our staff access to the services and data that they need to do their job.This includes (but isn't limited to) design files, generated assets (like thumbnails), database storage and database backups. All data that is stored in our infrastructure is encrypted at rest.We operate a load-balanced group of NGINX servers that terminate the Cloudflare TLS connections and pass the request onto their final destination.When a response from our origin servers is required, the request is sent using another TLS 1.3 connection to our infrastructure. TLS is terminated inside of Cloudflare's infrastructure so that some content can be cached.More detailed information is available at. The most secure version will always be used. The TLS version for this connection is negotiated between the user and Cloudflare. When a user connects to, their request is first routed to Cloudflare.All communication between users and Avocode is encrypted using TLS (up to version 1.3).Infrastructure Security Architecture Communication Security
0 Comments
Leave a Reply. |