June 28-29, 2016
New York, NY
We asked you to share your giant ideas, and you listened. This year we’re excited to announce our first round of sessions.
A few topics our engineers will present on are:
- Debugging MongoDB Performance in 3.2
- Big Data with MongoDB & Spark
- Financial Transaction Management and Analysis
- Using the Cloud Manager / Ops Manager API to Scale MongoDB With Your Application
MongoDB community members and customers will share their stories, including:
- Data Analysis and Visualization with MongoDB
- Containerizing MongoDB with Kubernetes
- Creating a Single View of the Customer
- From Story to Document: Modeling Common Business Problems with MongoDB
View our list of sessions stretching across a wide range of topics list below. New talks are added every week, so keep checking back!
Need more reasons to come? At MongoDB World 2016 in New York City, you’ll experience first-hand how the world’s fastest-growing database is powering today’s innovations and can help you gain a competitive advantage. Learn how large enterprises have delivered new applications to market at the speed of a lean startup, and how startups scale and execute on their giant ideas like an enterprise.
Securing MongoDB Part 2: Database Access Control
Welcome back to our 4-part blog series presenting the best practices and controls available in MongoDB to help you create a secure, compliant database platform. In this installment, we’ll be discussing database access control – covering both authentication and authorization. In part 1 , we took a look at the general requirements for data security and regulatory compliance. Looking ahead, in part 3 we’ll cover auditing and encryption. And in part 4 , we’ll wrap up with environmental control and management. If you want to get a head-start and learn about all of these topics in one installment, just go ahead and download the MongoDB Security Architecture guide . Enable Access Control and Enforce Authentication The first step in securing your MongoDB database is to enable access control. As new apps and services are in development, it is typical that access control is not enforced. But once these applications are ready for test and QA, then it is important to specifically enable it, thus requiring all clients and servers provide valid credentials before they can connect to the database. This ensures that you are not deploying exposed instances when you launch your app into production. Refer to the documentation for a tutorial stepping through how to configure authentication . Ensure that MongoDB runs in a trusted network environment and limit the interfaces on which MongoDB instances listen for incoming connections. Allow only trusted clients to access the network interfaces and ports on which MongoDB instances are available. See the Security Hardening section of the documentation to learn more about reducing the risk of exposure. MongoDB Authentication The authentication of entities accessing MongoDB can be managed from within the database itself, or via integration with an external mechanism (i.e. LDAP, x.509 PKI certificates, or a Kerberos service). MongoDB Enterprise Advanced , the certified and supported production release of MongoDB is required when using LDAP or Kerberos. In Database Authentication MongoDB authenticates entities on a per-database level using the SCRAM-SHA-1 IETF standard. Users are authenticated via the authentication command, while database nodes can be authenticated to the MongoDB cluster via keyfiles. Review the authentication documentation to learn more. MongoDB Atlas Authentication MongoDB Atlas is a database as a service for MongoDB, providing all of the features of the database, without the operational heavy lifting required for any application. MongoDB Atlas has been engineered to deliver robust access controls. Authentication is enforced for all MongoDB Atlas clients via the SCRAM-SHA-1 mechanism. User and administrator roles can be defined to ensure a separation of duties between different entities accessing the database and the MongoDB Atlas service. Clients are prevented from accessing the database unless their IP address has been added to the IP whitelist for your MongoDB Atlas group. Review the MongoDB Atlas documentation for more information on configuring the in-built security controls. LDAP Authentication LDAP is widely used by many organizations to standardize and simplify the way large numbers of users are managed across internal systems and applications. In many cases, LDAP is also used as the centralized authority for user access control to ensure that internal security policies are compliant with corporate and regulatory guidelines. With LDAP integration, MongoDB can authenticate users directly against corporate LDAP infrastructure to enforce centralised access policies. Note that MongoDB currently supports LDAP authentication, and not authorization. See the following section of this post to learn more about the authorization controls available in MongoDB. Administrators can configure MongoDB to authenticate users via Linux PAM or by proxying authentication requests to a specified LDAP service. A tutorial on configuring LDAP authentication is available in documentation. Kerberos Authentication With MongoDB Enterprise Advanced, authentication using a Kerberos service is supported. Kerberos is an industry standard authentication protocol for large client/server systems, allowing both the client and server to verify each others' identity. With Kerberos support, MongoDB can take advantage of existing authentication infrastructure and processes, including Microsoft Windows Active Directory. As with LDAP and x.509 certificates, before users can authenticate to MongoDB using Kerberos, they must first be created and granted privileges within MongoDB. The process for doing this, along with a full configuration checklist is described in the MongoDB and Kerberos tutorial . x.509 Certificate Authentication With support for x.509 certificates MongoDB can be integrated with existing information security infrastructure and certificate authorities, supporting both user and inter-node authentication. Users can be authenticated to MongoDB using client certificates rather than self-maintained passwords. Inter-cluster authentication and communication between MongoDB nodes can be secured with x.509 member certificates rather than keyfiles, ensuring stricter membership controls with less administrative overhead, i.e. by eliminating the shared password used by keyfiles. x.509 certificates can be used by nodes to verify their membership of MongoDB replica sets and sharded clusters. A single Certificate Authority (CA) should issue all the x.509 certificates for the members of a sharded cluster or a replica set. Instructions for configuration are described in the MongoDB and x.509 certificates tutorial . MongoDB and Microsoft Active Directory MongoDB Enterprise Advanced provides support for authentication using Microsoft Active Directory with both Kerberos and LDAP. The Active Directory domain controller authenticates the MongoDB users and servers running in a Windows network. MongoDB Authorization MongoDB allows administrators to define the specific permissions an application or user has, and what data they can see when querying the database. User Defined Roles MongoDB provides over ten built-in roles supporting different user and administrator privileges. These can be customised through User Defined Roles, enabling administrators to assign fine-grained privileges to users or applications. Authorization privileges can be based on the specific functionality a user needs in their role, or to reflect their organizational structure. MongoDB provides the ability to specify user privileges with both database and collection-level granularity. **Figure 1**: MongoDB User Defined Roles Permit Separations of Duty Privileges are assigned to roles, and roles are in turn assigned to users. For example: Classes of users and applications can be assigned privileges to insert data, but not to update or delete data from the database DBAs may be assigned privileges that enable them to create collections and indexes on the database, while developers are restricted to CRUD operations Certain administrator roles may have cluster-wide privileges to build replica sets and configure sharding, while others are restricted to creating new users or inspecting logs Processes for monitoring MongoDB clusters can be restricted to run just those commands that retrieve server status, without having full administrative access to perform database operations Within a multi-tenant environment, “landlord” developers and administrators can be assigned permissions across physical databases, while “tenant” developers and administrators can be granted a more limited set of actions across logical databases or individual collections. This functionality enables a clear separation of duties and control, both between and within organizations. To ensure ease of account provisioning and maintenance, roles can be delegated across teams, ensuring the enforcement of consistent policies across specific functions within the organization. Review the Authorization section of the documentation to learn more about roles in MongoDB. When combined with the auditing capabilities available with MongoDB Enterprise Advanced, customers can define specific administrative actions per role, and then log all of those actions. As a result, the organization is able to enforce end-to-end operational control and maintain insight of actions for compliance and reporting. MongoDB Field Level Redaction MongoDB’s field level redaction allows building access control to individual fields of document, working in conjunction with client-side code. Implemented via the redaction stage of MongoDB’s Aggregation Pipeline , developers are provided with a method to restrict the content of a returned document on a per-field level. Permissions can be based on both the content of the document and on specific user privileges, based on security labels. Access control policies can be described using the MongoDB query language, making it simple for developers to implement the required controls. Since data is redacted before it is returned to the application, exposure of sensitive information is reduced. Field level redaction is applicable to a wide range of sensitive data including personally identifiable information such as names, social security numbers, birthdates and bank account numbers. By co-locating data with different sensitivity levels within a single document, schema and query designs are simplified. **Figure 2**: MongoDB Field Level Redaction Restricts Access to Sensitive Data The redaction logic must be passed by the application to the database on each request. It therefore relies on trusted middleware running in the application to ensure the redaction pipeline stage is appended to any query that requires the redaction logic. Getting Started with MongoDB Security With comprehensive controls for user rights management, auditing and encryption, coupled with management controls, MongoDB can meet the best practice and requirements discussed in this blog series. MongoDB Enterprise Advanced is the certified and supported production release of MongoDB, with advanced security features, including Kerberos and LDAP authentication, encryption of data at-rest, FIPS-compliance, and maintenance of audit logs. These capabilities extend MongoDB’s security framework, which includes Role-Based Access Control, PKI certificates, Field-Level Redaction, and SSL/TLS data transport encryption. In the third part of this blog post series, we will dive into MongoDB auditing and encryption. You can learn about all of these capabilities now by reading the MongoDB Security Architecture guide. If you want to try them for yourself, [download MongoDB Enterprise](https://www.mongodb.com/download-center?#enterprise), free of charge for evaluation and development. MongoDB security architecture About the Author - Mat Keep Mat is a director within the MongoDB product marketing team, responsible for building the vision, positioning and content for MongoDB’s products and services, including the analysis of market trends and customer requirements. Prior to MongoDB, Mat was director of product management at Oracle Corp. with responsibility for the MySQL database in web, telecoms, cloud and big data workloads. This followed a series of sales, business development and analyst / programmer positions with both technology vendors and end-user companies.
The Rise of the Strategic Developer
The work of developers is sometimes seen as tactical in nature. In other words, developers are not often asked to produce strategy. Rather, they are expected to execute against strategy, manifesting digital experiences that are defined by the “business.” But that is changing. With the automation of many time-consuming tasks -- from database administration to coding itself -- developers are now able to spend more time on higher value work, like understanding market needs or identifying strategic problems to solve. And just as the value of their work increases, so too does the value of their opinions. As a result, many developers are evolving, from coders with their heads-down in the corporate trenches to highly strategic visionaries of the digital experiences that define brands. “I think the very definition of ‘developer’ is expanding,” says Stephen “Stennie” Steneker, an engineering manager on the Developer Relations team at MongoDB. “It’s not just programmers anymore. It’s anyone who builds something.” Stennie notes that the learning curve needed to build something is flattening. Fast. He points to an emerging category of low code tools like Zapier, which allows people to stitch web apps together without having to write scripts or set up APIs. “People with no formal software engineering experience can build complex automated workflows to solve business problems. That’s a strategic developer.” Many other traditional developer tasks are being automated as well. At MongoDB, for example, we pride ourselves on removing the most time-consuming, low-value work of database administration. And of course, services like GitHub Copilot are automating the act of coding itself. So what does this all mean for developers? A few things: First, move to higher ground. In describing one of the potential outcomes of GitHub Copilot, Microsoft CTO Kevin Scott said, ““It may very well be one of those things that makes programming itself more approachable.” When the barriers to entry for a particular line of work start falling, standing still is not an option. It’s time to up your strategic game by offering insight and suggestions on new digital experiences that advance the objectives of the business. Second, accept more responsibility. A strategic developer is someone who can conceive, articulate, and execute an idea. That also means you are accountable for the success or failure of that idea. And as Stennie reminded me, “There are more ways than ever before to measure the success of a developer’s work.” And third, never stop skilling. Developers with narrow or limited skill sets will never add strategic value, and they will always be vulnerable to replacement. Like software itself, developers need to constantly evolve and improve, expanding both hard and soft skills. How do you see the role of the developer evolving? Any advice for those that aspire to more strategic roles within their organizations? Reach out and let me know what you think at @MarkLovesTech .