Enterprise adoption of Kubernetes is widespread. But Kubernetes is complex, and many clusters are configured insecurely. An analysis conducted by Cyble found more than 900,000 Kubernetes clusters exposed over the Internet.\n\nThe importance of authentication and authorization configurations in K8s cannot be overstated. Luckily, Kubernetes supports a variety of authentication methods. Here are your top three options.\n\n➡️ Authentication proxy\nHere authentication is fully delegated to a proxy server through the Kubernetes API's authorization mode. By using this mode, the API receives requests from an intermediate proxy that handles authentication and sends HTTP headers with user details such as usernames and RBAC groups.\nSince Kubernetes API server does not have a way to validate the content of headers, only ensuring their provenance can protect the platform from header spoofing attacks. So authenticating proxy certificates must be validated by the API server against a valid X.509 client certificate.\n\n\n➡️ OpenID Connect\nA problem with the local authentication of remote users was solved by adding support for this authentication method to Kubernetes. By presenting a valid and unexpired JWT token, the OIDC authentication layer can validate users without relying on third-party authentication providers.\nYou can access your Kubernetes cluster with your identity provider infrastructure by integrating an OIDC integration, but granting different levels of access to each cluster is quite complex. Once tokens are issued, they are valid until their expiration date. Another thing to remember is that tokens cannot be revoked.\n\n\n➡️ Service Account Tokens\nServiceAccounts are used to control pod access to the Kubernetes API. You can attach RBAC (role-based access control) roles/permissions to the ServiceAccount that the pod is using, to increase the permissions the pod has.\nSimilarly to that, at Devolut we use a tool called Permission Manager, that lets us set up RBAC templates and create Kubernetes users (generated as ServiceAccounts in Kubernetes cluster). It has a clean and simple UI, which makes it easy to use, and generates Kubeconfig automatically for that user.\n👋 Say hi at \nhello@devolut.io\n and you won't have to worry about unauthorized users entering your company's infrastructure again.

Authentication for Kubernetes Clusters - Here is an overview of your best options

You're thinking about starting your own business. Maybe you just started it and built a proof-of-concept or MVP and now you're wondering how to move on in terms of cloud infrastructure. This article will explain how cloud infrastructure can work for you at various stages of your business.\n\nIt all starts with a couple of questions.\nFirst, let's look at a few questions that you might want to ask yourself before you begin your journey:\n\nHow do I choose a cloud provider? Do we have internal expertise in any of the major cloud providers (AWS, Azure, GCP)?\nIn what regions should my services be run, and what number of environments are planned for the initial stage (e.g. development, staging, production)? \nHow stable and predictable will our platform's load be? Will there be any spikes?\nHow important is it for us to manage and maintain our own infrastructure (databases, messaging brokers, etc.), or do we prefer cloud-managed solutions?\nWhat is our plan for building & deploying applications, both in terms of tools and strategy?\nDuring the initial phase, what level of downtime can we afford?\nAre we okay with having some basic security that can be improved later or do we need advanced security features from the beginning?\nAre we OK with basic monitoring features and basic infrastructure setup or do we prefer something more advanced?\n\nRelax, you got it.\nBefore you get overwhelmed by all the options, here's a very useful rule of thumb: \nstart small and modular. Infrastructure components can be easily added, or removed as you go.\n\nBuilding your first solid infrastructure\nStarting with AWS is a reasonable and safe choice (never use root credentials or root account for any operations though!). Then have experts create an initial Terraform setup (Infrastructure as a Code tool) where modules are defined (for each service that you will be running, e.g. an EKS Kubernetes cluster, an RDS database, an OpenSearch, etc.) and invoke from environment files or folders so that the basic structure is as follows:\n\nWith a structure like this, you can easily control which resources are deployed in which environment simply by adding small .tf files to the appropriate environment folder, such as development, staging, or production.\nSince these are just configuration files, they don't contain any actual logic for deploying them. This way, modules can be reused and implementation details can be hidden from end users, allowing them to focus on the end result rather than how Terraform works. For instance, you could decide that “my RDS database running Postgres will be named ‘my-db-postgres’ and it will run on a ‘db.m5.large’ machine” and provide that info via a simple config file which doesn’t overwhelm you with Terraform specifics.\n\nWhat about location?\nLocation or region should be chosen based on proximity to your current and potential user base. Just keep in mind that different regions have different pricing and not all regions offer all AWS services.\n\nDo you need Kubernetes?\nIt is possible that you already determined where and how your services will run in the first step. However, if you did not, now is the time for you to decide. We recommend running most of your services in Kubernetes clusters, in this case using AWS's EKS service, which you can set up via Terraform.\nThere is a substantial amount of knowledge and skill required to run K8s and services in it, especially during the initial setup phase. But once it's set up, it makes life easier for developers and the teams who support your stack. It has a wide range of options related to scaling, healing, keeping things secure, and many others.\nAdding functionalities to the K8s cluster\nAs soon as you have your base K8s cluster running, you should add a few components that will provide additional functionality, such as:\n\nkube2iam\n, which provides IAM credentials to containers running in a Kubernetes cluster\nExternal-DNS\n to synchronize exposed Kubernetes Services and Ingresses with DNS provider\nThe \ningress controller\n can be either Nginx, Traefik, or Kong. You can read more about ingress controllers in our post \nhere\n.\nCert-manager\n, which adds certificates and certificate issuers as resource types and automates certificate issuing and renewal\nCluster-autoscaler\n, which automatically adjusts the size of Kubernetes clusters according to a set of criteria\nECR-credentials\n, which automates the authentication process to ECR\nVelero\n for backup and restoration of K8s resources and persistent volumes\nVault\n for secrets and encryption management system\nIt's now time to deploy your apps. If your code is hosted on GitLab, you can use the CI/CD system built in GitLab, and write pipelines in YAML format (files called .gitlab-ci.yaml).\nPipelines should follow the same principle of keeping it simple, meaning as few steps as possible. It should build, deploy to development on every push or on merge into the main branch, and deploy to production manually or by tagging specific releases.\nAs there are several potential security concerns in integrating your CI/CD pipelines with the K8s cluster, we recommend handing this part over to experts.\nThe most common method of deploying into K8s is via native K8s manifest files or using Helm as a package manager. In this case, your apps will be packaged as Helm charts. This is our preferred option. For one app to be packaged using a generic helm chart (and deployed in the K8s environment), small values files are needed, in order to control how the generic helm chart is templated.\nOnce this is implemented and your CI/CD pipelines are deploying services, you need to make sure that Service/Ingress resources provide the least privileged access to applications.\nWe're not going to list all the resources and features that are needed to set up applications, but just mention a few: Readiness, Liveness, Startup probes (r/l/s probes), Horizontal Pod Autoscaling (HPA), and Pod Disruption Budget (PDB). These features are there to provide better availability & scalability of services and to ensure optimal deployments in general.\n\nYou don’t know if you can’t see.\nWith applications up and running, it's time to start collecting metrics and logs to provide insight into behaviors. \nPrometheus\n, \nGrafana\n, and \nAlertmanager\n are our preferred monitoring tools, and the ELK stack is our preferred logging tool. We highly recommend DataDog for monitoring & logging if you have a budget and like a nice user interface.\nKeeping backups for your databases and Kubernetes clusters is important to maintain in the event of equipment failure or catastrophe. We recommend Velero for Kubernetes backups. This tool allows you to select what resources to backup and when to backup them as well as where to store them. You can backup persistent volumes and restore whole Kubernetes clusters with just a few commands. Velero can also be used for migrations between clusters in addition to disaster recovery and recovery.\nBased on the type of database you are using, there are multiple tools available for database backups. As a standard, cloud platforms provide out-of-the-box backups for databases, but you can also use solutions like AWS Backup, which allows you to configure backups for different kinds of cloud services (EC2, DynamoDB, EFS, DocumentDB, or Neptune).\nThis is it.\nCongrats, you now have a reasonably solid foundation for future expansion and are ready for continuous support.\nThis is a fairly simple representation of the cloud infrastructure stack and its components (many topics are not covered for simplicity's sake). Our team at Devolut has built dozens of infrastructures from scratch. If you'd like to learn more about how to build and maintain a scalable system at your company, just say hi 👋 at \nhello@devolut.io\n and we'll gladly guide you along the way.

Starter pack: Building your first cloud infrastructure

When would you use object storage? The short answer is when you need to scale.\n\nA typical file system requires a single writer to ensure block mapping, directory entries, and partial file writings are performed atomically. Object storage does not have directories, but only allows you to add or replace objects. Having these limitations makes it easier to distribute your object storage across multiple servers.\nAWS S3, Azure BLOB, and Google Cloud Storage are the most popular object storage services. Let's check out their different tiers.\n\n\n🟢 AWS S3\n➡️ Amazon S3 Standard\nHigh throughput and low latency make this the best storage choice for information that is     accessed often, such as dynamic websites, cloud applications, content distribution, data analytics, and gaming.\n➡️ Amazon S3 Standard—IA\nA storage option for data that is accessed less often, such as disaster recovery.\n➡️ Amazon Glacier\nA highly durable storage system optimized for "cold" data, such as end-of-lifecycle records that are kept for compliance and regulatory backup purposes. It is immutable and encrypted for long-term storage.\n\n\n🟢 AZURE BLOB\n➡️ Hot access tier\nFor data in active use or about to be used and its subsequent migration to the Cool storage tier.\n➡️ Cool access tier\nFor long-term storage of data, including disaster recovery datasets, short-term backups, older media content and large data sets.\n➡️ Archive access tier\nFor archived data that can tolerate hours of retrieval latency and is kept longer than 180 days.\n\n\n🟢 GOOGLE CLOUD STORAGE\n➡️ Hot (high-performance) storage\nRegional and multi-regional high-frequency access information storage system.\n➡️ Multi-regional storage\nStores information that is often accessed around the world, including videos, website content, and mobile games.\n➡️ Regional storage\nProvides frequent access to information in the corresponding region.\n➡️ Nearline (cool) storage\nSuitable for backups and long-tail multimedia content that only needs to be accessed occasionally.\n➡️ Coldline (cool) storage\nArchival data and disaster recovery. Suitable for data accessed less than once a year. Now, the question of price – generally, the more performant and redundant the storage class, the more expensive it is.\n\n\n💡 If you're looking for a hybrid solution, you should definitely consider Minio. It implements the same public API as Amazon S3, so applications that talk to Amazon S3 can also talk to Minio. Minio is an object store that can store unstructured data such as photos, videos, logs, backups, and container/VM images. Files are separated into “buckets”, which are logical separators for your data, which need to be passed to applications along with connection keys, secret keys, and HTTP addresses.\n\nSay hi at \nhello@devolut.io\n and get more out of your cloud provider for less.\n

AWS S3 or Azure BLOB or GCS? Choosing an object storage

Today we'll look at AWS Direct Connect, Azure ExpressRoute, and Google Cloud Interconnect, three most popular solutions.\nCompared to internet connections, private connections can often increase bandwidth throughput, reduce overall network costs, and ensure a more secure and stable network experience.\nLet's go!\n\n➡️ AWS Direct Connect\nAWS has built a reputation as a robust cloud platform and attracted a large number of cloud users. With Direct Connect, you don't need to rely on local internet providers. In contrast to weakly secured public connections, Direct Connect customers can circumvent public internet connections while accessing AWS. This improves connectivity and minimizes network costs.\nYou are able to boost bandwidth speed without much effort, including data centers and backup servers. You can add more AWS tools while Direct Connect handles the increased load.\n\n➡️ Azure ExpressRoute\nAs with Direct Connect, ExpressRoute allows on-premises infrastructure to be connected to Azure. ExpressRoute has the benefit that Microsoft is a global giant whose solutions adhere to the law. So Azure users do not have to route customer data over the unencrypted internet or worry if their connection complies with the GDPR. \nAs Microsoft invests in equipment such as undersea cables, as well as the fact that its tools are widely used around the globe, users can rest assured that the chance of latency and compatibility issues is minimal.\n\n➡️ Google Cloud Interconnect\nWhile similar to its other two rivals, Interconnect offers something extra.\n🟢 Dedicated Interconnect connects the organization's on-premises infrastructure with Google Cloud resources and enables heavy data transfer. As Google's Interconnect is a physical connection, it eliminates the need for additional bandwidth to transfer massive amounts of data.\n🟢 Partner Interconnect offers a link between the customer's on-premises network and their virtual private cloud (VPC). Ideal for when the customer's data center is not reachable by Dedicated Interconnect or if the data needs do not exceed 10 GBPS.A major advantage of Interconnect over others is its ability to reach clients via third-party service providers. With your local internet provider already in place, you can establish Interconnect with ease.\n👋 We'll help you choose and implement a private connection so you and your team can focus on coding. Say hi at \nhello@devolut.io\n.

Blog

Phone:

Email: