One place for hosting & domains

      security

      Security On Autopilot: Best Practices for Securing Kubernetes Clusters


      Video

      About the Talk

      A high-level security checklist thats help you better secure your Kubernetes clusters throughout your container’s lifecycle. Get your 4Cs (Cloud, Cluster, Container, and Code) covered!

      What You’ll Learn

      • 3 common Kubernetes security mistakes
      • Kubernetes security best practices
      • Why it’s important to secure the container lifecycle

      This Talk Is Designed For

      Anyone looking to secure their Kubernetes clusters at all levels.

      Resources

      Slides

      About The Presenter

      Mamta Jha, Co-founder TechScalable
      Co-founder and enterprise architect with 17+ years of IT experience. Skilled cloud solutions architect with experience migrating, automating, and optimizing mission critical deployments in various cloud platforms, leveraging configuration management, CI/CD, and DevOps tools.



      Source link

      Managing Ongoing Security Concerns in MongoDB



      Part of the Series:
      MongoDB Security: Best Practices to Keep Your Data Safe

      MongoDB, also known as Mongo, is a document database used in many modern web applications. As with any database management system, it’s critical that those responsible for managing a Mongo database adhere to the recommended security best practices, both to prevent data from being lost in the event of a disaster and to keep it out of the hands of malicious actors.

      This series of conceptual articles provides a high-level overview of MongoDB’s built-in security features while also highlighting some general database security best practices.

      No matter how much effort you put into hardening your MongoDB installation’s security, it’s inevitable that new vulnerabilities will arise over time. As important as it is to run Mongo with secure settings from the outset, it’s just as important to perform frequent checks and diagnostics to determine the status of your system’s security.

      For instance, you should regularly check for new updates to MongoDB to ensure that the version you’re using doesn’t have any unpatched vulnerabilities. Mongo version numbers take the form of X.Y.Z, with X referring to the version number, Y referring to the release or development series number, and Z referring to the revision or patch number. MongoDB puts out a new release roughly every year, with the latest at the time of this writing being 4.4, but they also put out new revisions and patches as needed.

      While MongoDB generally recommends that you use the latest version available to optimize security, be aware that a new release series (meaning, from version 4.4 to version 4.6) can potentially break backwards compatibility. That said, MongoDB recommends that you always upgrade to the latest stable revision of your release series (meaning, if you have version 4.4.4 installed, you should upgrade to 4.4.5 when it’s available) as these are generally backwards-compatible patches intended to fix bugs.

      One should also consider how they intend to interact with their MongoDB database and whether that will change over time. MongoDB provides several commands and methods that allow you to perform server-side execution of JavaScript functions by default. As an example, you can use the $where operator to evaluate a JavaScript expression in order to query for documents. This provides you with greater flexibility, as it allows you to express queries for which there isn’t an equivalent standard operator. However, by allowing server-side Javascript execution, you’re also exposing your database to potentially malicious expressions. Hence, MongoDB recommends that you disable server-side scripting if you don’t plan on using it.

      Similarly, MongoDB will, by default, validate all user input to ensure that clients can’t insert a malformed BSON into the database. This input validation isn’t necessary for every use case, but MongoDB recommends keeping input validation enabled to prevent your database from storing any invalid BSON documents.



      Source link

      What is a Content Security Policy?


      A Content Security Policy (CSP) is a mechanism for web developers to increase the security of their websites. By setting a Content Security Policy, web developers can instruct web browsers to only load resources from certain trusted domains, enforce secure HTTPS connections, and even report policy violations as they occur. This can prevent many content injection and cross-site scripting (XSS) vulnerabilities, which often lead to data leaks, website vandalism, and malware distribution.

      Policies are transmitted to the web browser by either setting the Content-Security-Policy HTTP header, or including a <meta http-equiv="Content-Security-Policy" ... > tag in the HTML source of the site. The actual policy data is a text string, made up of one or more directives that specify the desired restrictions and configurations.

      To find out more about Content Security Policies, and their implementation in production applications, please refer to the following resources:



      Source link