devopsy.kinsta.cloud

Category: Traceable Cloud Native

  • Cloud Security Requires Shared Responsibility

    Cloud Security Requires Shared Responsibility

    The Growth of Public Cloud and the Need for Cloud Security

    Since 2006 when Amazon first introduced EC2 — the first public cloud service — cloud has become a major staple of enterprise information technology strategy. Both Infrastructure as a Service (IaaS) and newer cloud services continue to grow robustly. Enter the need for cloud security.

    While providing undeniable benefits to users such as scalability, speed to market, and cost savings, public cloud offerings also created a new dilemma: Just who was responsible for security when the platform was no longer protected on the user’s  premises,  and was in some part controlled by a third-party vendor?

    Cloud security is an issue the industry has had to solve in order to achieve such impressive growth. Since 2014, security services have been a key focus area of cloud providers. This includes protection of the infrastructure itself and tenant boundaries, as well as advanced services protecting the data itself. Without security, no reasonable enterprise would use public cloud in production.

    AWS Approach To Shared Responsibility Model

    As a public cloud pioneer, Amazon Web Services (AWS) was the first provider to introduce the term “shared responsibility model” and its components, starting to think about improving  cloud security to a level sufficient to protect enterprise production workloads.

    According to Amazon:

    ‍“Security and Compliance is a shared responsibility between AWS and the customer. This shared model can help relieve customer’s operational burden as AWS operates, manages and controls the components from the host operating system and virtualization layer down to the physical security of the facilities in which the service operates. The customer assumes responsibility and management of the guest operating system (including updates and security patches), other associated application software as well as the configuration of the AWS provided security group firewall.”

    In short, AWS secures the cloud’s physical infrastructure, compute, and network systems  from outside physical access and from digital access and insider threats.  The customer’s responsibility is to protect everything they run in the cloud.

    What Needs To Be Secured in a Cloud Deployment?

    The importance of security in the context of public cloud has led to formation of the Cloud Security Alliance (CSA). CSA has their own interpretation of the shared responsibility model.

    From the CSA’s perspective, the following are the categories of cloud systems that need to be secured:

    Information and Data – Data are the crown jewels of any digital business. From the addresses of paying customers to sensitive financial records and employees’ information ,  protecting data is critical to the success of any online business. Further, many compliance regulations, especially the recent focus on GDPR and CCPA, exert additional pressure to protect personally identifiable information.

    ‍Application Logic, APIs, and Code – The data are interpreted and processed by the application logic and application programming interfaces, or APIs. The code that implements applications can represent a core competitive advantage for the enterprise, but the logic itself and protection of the APIs is extremely important for securing  both the business and its data.

    ‍Users, Authentication, and Access Control – Users — who are both owners of the data and the source of revenue for the online business — , also need protection. From account takeover to identity theft, malicious actors can harm the users. The owner of the service where such attacks take place  is ultimately responsible for providing security.

    ‍Platform and Resource Configuration – This is the only major component of the cloud that is protected by the cloud provider itself. Protection is typically extended to the physical premises, computing resources, including cooling and physical maintenance requirements, network resources, virtualization systems and hypervisors, resource management systems, storage systems and so on.

    As Platforms Evolve, Does Shared Responsibility Change as Well?

    Newer cloud services go beyond providing just infrastructure-as-a-service and may influence how we think about shared responsibility.

    For example, some of the more interesting platform offerings include serverless compute services, a cloud development model that allows developers to build and manage applications without having to worry about server management. These offerings include  AWS Lambda, AI-as-a-service, (such as Google Cloud AI), and hosted blogs like Medium.

    If the application uses one of these advanced services, it changes how the shared responsibility model is applied because the provider is not just responsible for the host, but also for the security of the platform itself.

    While this helps us sort out security responsibilities, we must still consider security of information and data (think hosted WordPress blog); security of intellectual property and code (such as the case with serverless);  and security of the API and application logic (as might be the case with a hosted Kubernetes infrastructure, Amazon Elastic Kubernetes Service or Azure Kubernetes Service). All these data, application logic and code elements should still be secured by the cloud user or enterprise according to the shared responsibility model.

    There are a couple of additional important security considerations for newer platforms. Watch out for cloud lock-in. While running a guest Linux OS makes it extremely easy to migrate  workloads back on premises or to a different cloud, running the logic on a hosted platform makes the migration more difficult: the logic becomes dependent on the provider APIs. Secondly, data flows and compliance becomes a touch more difficult because best practices are not as well established for newer platforms.

    How Traceable Can Help with Cloud Security

    Traceable Defense AI provides application protection that helps fill in the customer’s share of the shared responsibility, especially as data flows, application logic, and APIs are concerned.

    Data flows – Traceable observes the data flows throughout the application running on the platform and identifies sensitive data for compliance purposes.

    API security in pre-production and production – Traceable maps out the application flows, protects applications and APIs from run-time threats, assesses API risks and helps with threat analysis and compensating controls.

    User-centric view – Traceable identifies suspicious activities and anomalies. When suspicious activity is detected on a previously well-behaved account, it’s an indicator of an account compromise. Combined with a rate-limiting functionality, this helps protect legitimate users.

    Traceable is a born-in-the-cloud company that prides itself on helping enterprises adopt cloud-native architectures in production. Understanding the shared responsibility model, selecting the cloud provider that holds up their end of the bargain, and using the right cloud security tools to fulfill the enterprise share of security responsibility is what will make the cloud truly secure.

    To learn more about Traceable you can visit us at https://traceable.ai or view a recorded demo.

  • Securing Microservices Vs. Monolithic Apps

    Securing Microservices Vs. Monolithic Apps

    New requirements for Securing Microservices Vs. Monolithic Apps

    Enterprises are migrating from monolithic applications to microservices, hoping to accelerate software deployment and improve scalability. Security is sometimes glossed over in these transitions.

    Simple best practices like authenticating users and using SSL are still important to follow. But teams need to think through important differences between the two architectures to ensure new risks are not inadvertently introduced.

    As you begin  migrating from a monolith to microservices, some of these issues may seem relatively trivial. But left unaddressed they can create substantial security vulnerabilities, reduce performance, and result in technical debt.

    Some of the most important differences to consider include the number and size of attack surfaces, and how and where teams manage business logic security. Teams also need to think through the additional complexity of increased communication between microservices running in separate containers or machines. New issues also need to be addressed when application state is stored externally.

    1. One Larger Versus Many Smaller Attack Surfaces

    The biggest difference relates to the size and number of attack surfaces. A monolithic application is by definition a single application with a single attack surface. In contrast, a microservice architecture spreads the same functionality across multiple, independently running microservice applications, each with their own attack surface.

    The attack surface on the single monolithic app is also larger than on each microservice because the application has far more responsibilities to control.  In contrast, the attack surface of each microservice is much smaller because they are limited in what they can do. In traditional web application security, a web application firewall can protect the entire application in aggregate. With microservice security, however, teams need  to think about securing the connections to each microservice using a more adaptable firewall.

    2. Managing Business Logic Security

    Web application firewalls provide a front line of security to track what clients are requesting data and ensuring they have the appropriate credentials. Monolithic applications often add an additional layer of business logic security using a servlet. This performs logical filtering within the app itself to ensure requests are reasonable before passing them to the appropriate component.

    As a result, monolithic app components can operate on the assumption that the request has been validated at the application programming interface (API) level by the servlet. The servlet can keep track of who is making calls into the application and block requests that fall outside the bounds of normal behavior. A microservice rarely if ever has any idea about what has been done between other microservices. They are typically designed to operate independently from the details of everything around them, which means that business logic-level attacks are easier to perpetuate.

    3. Service-To-Service Complexity

    In a traditional monolith, messages are passed between functions within the application. In a microservice architecture, this traffic passes between multiple services that may reside behind a common firewall or separate firewalls.

    Developers may mistakenly believe these communications are safe when the messages are passed between services that exist behind a common firewall. But because of the dynamic nature of microservices, sometimes these communications are passed over wider networks. There can be security issues when data is passed between applications in plain text.

    Teams should consider encrypting data in transit as it is passed between microservices, and then encrypting data at rest when it is stored.  This encryption requires teams to think about creating an encryption process that runs in conjunction with provisioning and managing microservices. Each service needs to be provisioned with a public certificate and private key. There also needs to be a method for revoking  certificates and issue new ones when services are decommissioned or compromised.

    4. Authentication Latency

    Microservices can also increase the number of authentication steps required to execute a transaction. In traditional application security, an API security service only needs to secure one link between client and server.   With microservice security, additional consideration needs to be given to securing the connection from a client to each microservice and to the calls between them. This increases the number of security steps required for requesting and processing security tokens. Unless this process is efficiently engineered, each request can add latency and degrade performance.

    Some organizations may skip some of these steps, under the assumption that these services are communicating on a secure virtual private network. However, this can increase app vulnerabilities if the network is compromised. Another approach lies in implementing a better strategy for API security.

    5. Immutability

    Monolithic applications manage data as part of their operations. In contrast, microservices are architected so all data is stored external to the microservice, which is called immutability because the service does not change state. This makes it easier to spin up new instances or kill running ones without affecting the application as a whole. But because the microservice itself does not change, an external process needs to maintain a list of which microservices are allowed to talk to others. These need to be managed centrally and then either pushed out or pulled in to each microservice automatically.

    Another challenge is data integrity. In a traditional application, the state of a transaction can be monitored internally; if a step cannot be completed the entire transaction can be rolled back. In a microservice architecture this kind of state management needs to be managed externally.

    6. More Services To Monitor

    Traditional infrastructure-based monitoring was designed for providing endpoint and server security. Microservices generate more traffic between services at a finer level of granularity,  which can make it harder to automatically enable application observability through metrics, logs, and tracing. This is difficult enough just for measuring operational health, and even harder for tracking security posture.

    Another challenge confronting security designers lies in ensuring consistency for application observability data generated across microservices. At the least, security requires good logging and integration into incident response systems to alert security analysts to the possibility of subtle and slow-moving security breaches. More sophisticated approaches can combine these richer data sets with machine learning to help detect and block attacks without burdening teams with false positives.

    Planning for a New Security Posture

    None of these security concerns should be deal breakers for transitioning to a microservices architecture. But as enterprises begin to scale up their microservices implementation, these issues will grow in complexity. A little planning upfront could reduce the need for significant rework down the line.

    Security tools such as Traceable’s Defense AI are emerging to address these challenges in a more automated way. The key lies in balancing the appropriate set of rich observability data and machine learning, with a deep understanding of the rapidly evolving API threat landscape.

  • Secure Kubernetes Architecture: Six Factors Essential to Success

    Secure Kubernetes Architecture: Six Factors Essential to Success

    Kubernetes has become the go-to container orchestration tool for businesses.

    Check out these telling stats [source: Enterpriser’s Project]:

    • 84% of companies are using containers in production.
    • Of those, 78% are using Kubernetes to manage their containers.
    • 69% of companies have found security holes due to misconfiguration of their Kubernetes environment.

    Your Kubernetes architecture is like a large house with container “tenants” living inside it. You’ll need to build it with care to make sure it’s a safe and happy place to live.

    Here are six essential factors to get right when planning (or auditing) your Kubernetes architecture.

    Setting the Foundation: Underlying Platform and Control Plane Configuration

    The foundation of a house is a critical first step. A weak foundation leads to cracks over time.

    Similarly, where you install Kubernetes is your first choice. There are several options available, each with pros and cons.

    Kubernetes is a cloud-native tool. Therefore, it makes sense to install it on the cloud. There are two cloud deployment options: Infrastructure as a Service (IAAS) or Platform as a Service (PAAS).

    An IAAS installation involves creating a series of virtual machines in the cloud (for instance, using Amazon EC2) and installing Kubernetes on those machines. You’ll be responsible for updates and configuration of the Kubernetes installation.

    On the other hand, all major cloud providers offer managed Kubernetes services. This deployment model allows you to use Kubernetes without having to handle the infrastructure.

    Even though Kubernetes was made for the cloud, you don’t have to install it in the cloud. An on-prem installation is an option, with many companies choosing to use their virtualization infrastructure to host Kubernetes.

    You’ll find a quick summary of the pros and cons of each choice below.
    ‍

    Your decision depends on three factors:

    • The skillset of your team
    • Your need for control and flexibility
    • Your company’s goals

    Control Plane Configuration

    The Kubernetes Control Plane consists of the services run on the Master node. The cluster store, scheduler, controller manager, and API server combine to create the control plane.

    Plan your control plane security well. If an attacker gains access to your control plane, they’ll be able to control your entire Kubernetes cluster. Use SSH or a VPN / VPC to connect to and use the control plane.

    If you’re using a managed service from a cloud provider, protect your API keys and credentials. Don’t ever store them in a source control system. Losing your API keys would lead to a complete takeover of your cloud infrastructure, not only your Kubernetes installation.

    Finding Good Tenants: Container Security and Composition Analysis

    The wrong tenants can destroy your house. Similarly, dangerous containers can bring down your Kubernetes environment.

    Make sure any containers you bring in from the outside are vetted and configured correctly. Only use trusted registries, such as Docker Hub or Quay.io.

    Finally, scan your containers before using them. You can use open-source container scanners to find vulnerabilities and malware. You can integrate most scanners into your CI/CD pipeline.

    Plan Your Rooms Wisely: Kubernetes Cluster Partitioning

    The rooms in your house each have a different name and purpose. You don’t keep a stove inside your bedroom or a bed in the kitchen. You give tenants private rooms while allowing them to share common areas, such as the kitchen.

    In Kubernetes, namespaces allow you to separate various applications within the same cluster logically. If the cluster is your house, each namespace is a separate room within it.

    Give namespaces to each application within your cluster. This practice produces three benefits:

    • Logically separates applications and environments (Development, Staging, Production)
    • Allows for robust Role-Based Access Control (RBAC)
    • Allows for network partitioning for added security within the cluster

    Kubernetes RBAC Primer

    You can check out the Kubernetes docs for comprehensive explanations of RBAC within Kubernetes. But here’s a quick primer for those who don’t have the time to read it now.

    Kubernetes has Roles and ClusterRoles. They contain rules that represent a set of permissions. There are no “deny” rules, so you have to know what access is necessary.

    Each Role is scoped to a specific namespace. ClusterRoles, on the other hand, have no namespace. In Kubernetes, an object can only be namespaced or not; it can’t be both. Therefore it’s necessary to have two resources, one for each scenario.

    Use Roles to create permissions tied to a specific application. Use ClusterRoles for access to cluster-scoped resources or resources used by multiple namespaces.

    RoleBinding and ClusterRoleBinding is the act of assigning permissions to a specific user. A RoleBinding grants permissions within a single namespace while a ClusterRoleBinding grants access cluster-wide.

    For example, assigning the “pod-reader” Role to the user “jane” in the “default” namespace allows “jane” to read pods in the “default” namespace.

    Roles define a set of permissions. Then users, groups, or service accounts (collectively called “subjects”) are assigned roles to grant access to specific resources within the cluster.

    Define network partitioning and access control appropriate for the business’s needs before deploying any application into your cluster.

    Watch Your Wiring: Inter-Pod Communications

    Shoddy wiring is more than an inconvenience. It can lead to damaging fires or even destroy the entire house.

    Similarly, poor inter-pod communications can bring your Kubernetes cluster grinding to a halt.

    A Kubernetes environment is a small network ecosystem. The same network topologies, protocols, and policies govern pod-to-pod communication as those you’d find in any corporate network.

    A full discussion of Kubernetes networking is beyond the scope of this article. You can read up on it using the Kubernetes networking documentation. But here are some quick pointers.

    You can use Service Topology to define how traffic flows to and from a particular service. For example, a service can specify that traffic should be routed to endpoints on the same node as the client.

    Service Topology is useful in the public cloud. You can use it to keep a service’s traffic in a particular availability zone or region to reduce latency.

    Another useful networking tool is NetworkPolicies. These application-level constructs specify how a pod is allowed to communicate with other entities. This feature is especially useful when you want to control network traffic using IP addresses or ports.

    Finally, you need to have a robust authentication and authorization strategy. We recommend using a service mesh to simplify load balancing, service discovery, encryption, and authentication. For example, service meshes include support for OAuth, which makes service authorization much easier to manage.

    Secure the Front Door: Ingress Architecture

    There’s no point in building a secure home and then leaving the front door unlocked. You don’t want to do that with your Kubernetes cluster either.

    In Kubernetes, Ingress exposes HTTP and HTTPS routes from outside the cluster to your services within it. Ingress is your environment’s “front door.”

    [source: Kubernetes docs]

    Carefully consider which server to use in your Ingress architecture. NGINX is a tried and true web server with all of the security features necessary to protect your services. NGINX now offers an Ingress Controller for cloud-native Kubernetes environments.

    However, you may want to give Envoy a look. It’s an open-source edge and service proxy built by Lyft specifically for cloud-native applications. It tackles the common observability and network debugging issues common in a microservice architecture. Envoy can also serve as a service mesh.

    As the “front door” to your cluster, the choice of an Ingress server also impacts security. You can use it to terminate TLS connections from clients before they access your services. Be sure to include a key management strategy, including a Key Management Service or another secure vault.

    Remember to follow the same security practices for your Kubernetes cluster as you do for any other part of your network infrastructure. Watch for OWASP Top 10 and OWASP API Top 10 vulnerabilities as well as logic-based threats.

    (Hint: Traceable watches for common and logic-based vulnerabilities by learning the business logic of your microservice applications. Check it out for yourself here).

    Finally, make sure your ingress plays nicely with mobile and IoT devices if you serve those clients.

    Install Security Cameras: Secure and Monitor Microservice Communications

    Video doorbells and security cameras are becoming commonplace. Homeowners want to know what is happening in and around their house.

    Securing and monitoring within your Kubernetes cluster is equally critical. Make sure that microservice communications are protected, and you know what requests are being sent between services.

    Consider point-to-point encryption between all microservices. And ensure real-time API monitoring for both REST and gRPC protocols.

    Zero Trust principles not are becoming more popular as new technologies are appearing that support it. Zero Trust is an operating model where no traffic is trusted by default, inside or outside your network.

    Within Kubernetes, implementing this model means verifying every request, client, or object trying to connect to your services. Nothing happens within your cluster unless the user or service account has proven that they have permission to act.

    Zero Trust is essential to cloud-native security. At any moment, dozens or hundreds of services are trying to perform actions and share information. Zero Trust ensures that every request is validated and there are no holes due to the assumption that internal traffic is automatically safe.

    Protect Your House

    The world of microservices and cloud-native architecture unlock countless opportunities for businesses today. But new technologies also come with new dangers; new opportunities for malicious actors to steal sensitive information.

    We’ve discussed six essential factors for securing your Kubernetes architecture:

    1. Choosing the underlying platform and control plan configuration
    2. Vetting and securing the containers running in your environment
    3. Implementing cluster partitioning and access control
    4. Defining inter-pod communications
    5. Choosing your Ingress architecture (protecting your “front door”)
    6. Securing and monitoring your microservice communications

    With these factors in mind, what should your next steps be?

    If you have an existing Kubernetes installation, use these factors as a mini-audit. Review your current policies and see how well they match up in these six areas.

    If you’re planning your first Kubernetes installation, use these factors as a guide to making sure you cover all of your bases. Meet with implementers and make sure you have a plan for all of these factors.

    Then your Kubernetes environment will be a happy home for your microservices.