Understanding the internals of Emp Cloud
Emp Cloud is a platform for building and deploying AI agents and web3 applications.
It is an abstraction layer on top of AWS infrastructure and kubernetes. We have developed multiple kubernetes controllers and CRDs to automate and manage the provisioning, lifecycle and perimeter of the infrastructure.
We currently build on the following open source operators:
What happens when you create a new project?
Creating a new project through empctl interacts with a series of custom k8s resources that expand into multiple AWS resources on the fly.
The reconciliation logic is implemented as a series of controllers that watch for changes in the custom resources and update the corresponding AWS resources.
The resources are available almost instantly and the will be cleaned up when the project is deleted.
Understanding the security model
To minimize the attack surface of our infrastructure, users do not have access to the AWS credentials or resources directly.
The provisioning of infrastructure components also creates the necessary IAM roles and policies for them to be accessed only by the project's namespace and the containers that are running on it.
On more complex occasions, like accessing an ECR token to push a docker image or updating secrets we have developed a flow that involves triggering jobs in the namespace to do these operations.
So, for example, for accessing an ECR login token, first empctl will create a job in the namespace that will interact with the ECR API and get the login token, then the token will be forwarded to the user's local machine or CI/CD system to be used for pushing the actual image. The process is seamless and doesn't require any additional configuration or elevated permission system.
On the more complex scenario of updating secrets securely, to avoid exposing credentials or MITM attacks, the flow involves empctl uploading the secrets to a presigned URL and then triggering a job in the namespace that accesses the URL and updates the secrets on the AWS Secret Manager secret. Additionally, the actual secrets are being fetched on the cluster securely through the External Secrets Operator and stored in a k8s secret that is mounted on the pods running on the namespace.
Last updated