mongo atlas provides a reasonably priced access to a managed mongo DB. CSPs where containers are hosted charge too much for their managed mongo DB. they all suggest setting an insecure CIDR (0.0.0.0/0
) to allow the container to access the cluster. this is obviously ridiculous.
this entrypoint script is surgical to maintain least privileged access. only the current hosted IP address of the service is whitelisted.
related searches, hope this shows up for you
- "How to connect to mongodb atlas cluster to container app service EKS ECS cloudrun compute engine"
- "mongodb atlas cluster access without using whitelist 0.0.0.0"
- "secure mongodb atlas cluster access on digital ocean GCP AWS vultr heroku"
- set as the entrypoint for the
Dockerfile
(after executing it will exec theCMD
on the last line) - or use as cloud init / startup script in VM (remove the last line,
exec "$@"
)
uses the mongo atlas project IP access list endpoints
- will detect the hosted IP address of the container and whitelist it with the cluster using the mongo atlas API
- if the service has no whitelist entry it is created
- if the service has an existing whitelist entry that matches current IP no change
- if the service IP has changed the old entry is deleted and new one is created
when a whitelist entry is created the service sleeps for 60s to wait for atlas to propagate access to the cluster
setup
- for name set
whitelist management: <project name>
so it is easily identifiable across your projects - for Project Permissions select
Project Owner
role - do not define an IP access list for the key - it must be usable from any IP for the script to work
note: elsewhere in the docs it is claimed you have to first create an org key then "invite" it to the project. this is not necessary. just creating the project API key will automatically create an org key with the correct role scope of
Organization Member
.
if you go the long route make sure you set the correct scope for the org key. it should be
Organization Member
NOTOrganization Owner
. the latter is effectively a "root" scope which is far too much privilege. TheOrganization Member
combined with a project key role ofProject Owner
will give the least access necessary for the script to operate on the cluster associated with the project
- copy the public key (
MONGO_ATLAS_API_PK
) and secret key (MONGO_ATLAS_API_SK
) - go to project settings page (Settings in the left nav-bar) and copy the project ID (
MONGO_ATLAS_API_PROJECT_ID
)
confirm you have the correct configuration for the key
- the org key should have
Organization Member
- you can view this at the top Access Manager > Organization Access > API Keys tab
- the project key (really is just the org key scoped to this project) should have
Project Owner
- neither key should have any access list restriction
provide the following values in the runtime env of the service executing the script
SERVICE_NAME
: unique name used for creating / updating (deleting old) whitelist entryMONGO_ATLAS_API_PK
: step 3MONGO_ATLAS_API_SK
: step 3MONGO_ATLAS_API_PROJECT_ID
: step 4
- bash
- curl
- jq CLI JSON parser
# alpine / apk
apk update \
&& apk add --no-cache \
bash \
curl \
jq
# ubuntu / apt
export DEBIAN_FRONTEND=noninteractive \
&& apt-get update \
&& apt-get -y install \
bash \
curl \
jq