Finisky Garden

This is part3, we will expose the user database pods to the public so that Mongo client is able to access it.

MongoDB Ops Manager Series:

1. Install MongoDB Ops Manager
2. Create a UserDB ReplicaSet
3. Expose UserDB to Public
4. Openssl Generates Self-signed Certificates
5. Enable UserDB TLS and Auth

So far, the user database can be accessed only inside the kubernetes cluster. The official blog's approach is to expose the pods by NodePort: # Connect to a MongoDB Database Resource from Outside Kubernetes

I don't know why the official blog recommend NodePort. Obviously, LoadBalancer is a better way to expose MongoDB. We will use LoadBalancer to expose userdb pods.

This is part2, we will create a user database that is a 3 instances ReplicaSet.

MongoDB Ops Manager Series:

1. Install MongoDB Ops Manager
2. Create a UserDB ReplicaSet
3. Expose UserDB to Public
4. Openssl Generates Self-signed Certificates
5. Enable UserDB TLS and Auth

The so called Application Database is the backend DB of Ops Manager. It cannot be used to store user data. The user database is called MongoDB Deployment. Note that the deployment is different with Kubernetes deployment.

For simplicity, we will create a replicaset instead of a sharded cluster. The configuration process is almost the same. Because sharded cluster consists of more components, the configuration is more complicated. Let's start with an easier one. :-)

Reference: Deploy MongoDB Sharded Cluster by Ops Manager

Unfortunately, creating user database cannot be directly done by the Ops Manager web UI. Most of the operations should be performed by the MongoDB Kubernetes Operator, aka the kubectl command line. If you try to create it through web UI, you need to manually configure variety of parameters and install Agents which I don't know how to do it. So to my understanding, Ops Manager is a great tool for visualization and automation tasks, but not good at cluster manipulation. I think the reason is that the cluster specification is too complicated to incorperated to the UI.

It's pretty easy to configure a MongoDB standalone instance (almost zero configuration). However, if you want to run a production-level MongoDB cluster, the configuration process is non-trivial. For a production cluster, replication/sharding/dyanmic scaling/backup/transport encryption/monitoring are required. Is there a nice tool to help us?

MongoDB cluster is a distributed system, which is well suited to run in Kubernetes. However, the collaboration of MongoDB instances usually need to manually run commands on each instance which is independent of Kubernetes. Therefore, MongoDB Enterprise Kubernetes Operator is developed to mitigate the gap. Morever, MongoDB Ops Manager is a great web portal to help these automation tasks.

The whole deployment and configure process is a little bit long, I wrote a series of small pieces to make each of them compact and easy to follow:

1. Install MongoDB Ops Manager
2. Create a UserDB ReplicaSet
3. Expose UserDB to Public
4. Openssl Generates Self-signed Certificates
5. Enable UserDB TLS and Auth

Prerequisites

• Have a Kubernetes cluster
• Basic understanding of MongoDB
• Basic understanding of Kubernetes deployment/service/statefulset
• Familiar with kubectl operations

This is part1, we first introduce the MongoDB Ops Manager components, then install it into your Kubernetes cluster.

本文为系列第五部分，用生成的自签名证书打开userdb的TLS和AUTH，并且完成userdb的公网域名访问。

整个系列：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

本文为系列第四部分，相对独立，先生成一个自签名CA证书，然后生成MongoDB各个server证书。

整个系列：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

自签名证书不推荐在生产环境使用，虽然它可以保证通信过程中的加密，但不能避免中间人攻击。Public Key Infrastructure (PKI)相关的内容也不在本文的讨论范围，这里假设读者对PKI已有基本的认识。

本文为系列第三部分，使用第二部分创建好的userdb可以从公网访问，方法是通过Kubernetes Service暴露userdb pod到公网上。

整个系列：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

官方文档是通过NodePort的方式暴露给公网，而我们这里是通过创建service的方式完成，好处是这种方式不必管理pod和node之间的端口映射，也不必担心pod被调度到不同node上之后IP的改变。不知道官方使用NodePort进行服务暴露是基于怎样的考虑。 # Connect to a MongoDB Database Resource from Outside Kubernetes

本文为系列第二部分，使用第一部分安装好的MongoDB Ops Manager创建用户数据库。

整个系列：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

所谓的Application Database是MongoDB Ops Manager的后端DB，并不能用来存放用户数据，所以我们需要用Ops Manager创建用户数据库。使用Ops Manager创建的MongoDB叫做Deployment，注意此Deployment是MongoDB Deployment，与kubernetes的Deployment不是一码事。

简单起见，本文以创建一个3实例的MongoDB userdb为例，Sharding Cluster由于组件复杂，server数量更多，配置比ReplicaSet要麻烦些，但配置过程基本一致。可参考： MongoDB Ops Manager部署Sharded Cluster

MongoDB的入门配置门槛（单机）很低，但如果想达到生产环境的要求则有些技术含量。生产环境的配置要求包括Replica Set、Sharding、Scale up/down、数据备份、通信加密TLS和指标实时监控等。配置这些功能比较繁琐，有不少坑要踩。那么有没有好用的工具帮我们配置和管理呢？

MongoDB是个分布式系统，且需要动态的增加或删除节点，那么与kubernetes结合使用则是珠联璧合。结合之后就需要一套kubernetes工具对其进行管理，它就是MongoDB Enterprise Kubernetes Operator，更进一步，可以使用MongoDB Ops Manager完成上面所有生产环境的配置需求。

整个配置流程比较繁杂，为不使一篇万字长文吓到读者，写成了系列教程，力求每一块简明内聚：

1. 安装MongoDB Ops Manager
2. 创建用户数据库(replicaset)
3. 用户数据库服务配置公网访问
4. openssl生成自签名CA证书和server证书
5. 打开用户数据库TLS通信加密和Auth授权

阅读教程前提：有Kubernetes集群，了解deployment/service/statefulset含义，熟悉kubectl基本操作。

本文为系列第一部分，简介MongoDB Ops Manager Kubernetes的构成，以及如何安装MongoDB Ops Manager。

如果你按官方文档 Configure mongod and mongos for TLS/SSL 配置MongoDB证书，可能会遇到如下问题：

{"t":{"$date":"2020-11-30T08:02:19.406+00:00"},"s":"E",  "c":"NETWORK",  "id":23248,   "ctx":"main","msg":"Cannot read certificate file","attr":{"keyFile":"/etc/ssl/testserver1.pem","error":"error:0200100D:system library:fopen:Permission denied"}}
{"t":{"$date":"2020-11-30T08:02:19.406+00:00"},"s":"F",  "c":"CONTROL",  "id":20574,   "ctx":"main","msg":"Error during global initialization","attr":{"error":{"code":140,"codeName":"InvalidSSLConfiguration","errmsg":"Can not set up PEM key file."}}}

or

{"t":{"$date":"2020-11-30T08:01:14.545+00:00"},"s":"I",  "c":"ACCESS",   "id":20254,   "ctx":"main","msg":"Read security file failed","attr":{"error":{"code":30,"codeName":"InvalidPath","errmsg":"permissions on / are too open"}}}

真难伺候，一会儿没权限读证书，一会儿权限太开放了，到底证书要什么权限？官方文档没加个tips解释这些细节，可能假设用户对PKI和证书这套东西非常熟悉。

运行mongod的用户是mongodb，所以看起来证书权限需要是：能让用户mongodb读此证书但不能修改。

When you setup TLS/SSL for MongoDB Configure mongod and mongos for TLS/SSL, you might encounter the following errors:

{"t":{"$date":"2020-11-30T08:02:19.406+00:00"},"s":"E",  "c":"NETWORK",  "id":23248,   "ctx":"main","msg":"Cannot read certificate file","attr":{"keyFile":"/etc/ssl/testserver1.pem","error":"error:0200100D:system library:fopen:Permission denied"}}
{"t":{"$date":"2020-11-30T08:02:19.406+00:00"},"s":"F",  "c":"CONTROL",  "id":20574,   "ctx":"main","msg":"Error during global initialization","attr":{"error":{"code":140,"codeName":"InvalidSSLConfiguration","errmsg":"Can not set up PEM key file."}}}

or

{"t":{"$date":"2020-11-30T08:01:14.545+00:00"},"s":"I",  "c":"ACCESS",   "id":20254,   "ctx":"main","msg":"Read security file failed","attr":{"error":{"code":30,"codeName":"InvalidPath","errmsg":"permissions on / are too open"}}}

So what's the right ownership and permission for the certificate pem file? The answer is: the pem file should have read access but no write access for the user mongodb.