Securing Microservices Based on Zero Trust Policy

Within a zero-trust policy, AWS IAM resource policies and execution roles are required as the default security measures. As part of this, default to deny configurations as part of these policies are needed.

It is also required that role permissions for executing applications should be limited to each application’s permissions boundaries. For example, a Lambda should have an execution role that can be extended should it need to use additional actions that it does not need by default, such as being able to access elements within the application itself. These may also involve permissions requiring the usage of said elements from different regions or resources across those regions.

To track functions of a similar nature and secure them accordingly, tagging would be recommended. Using compliance services such as AWS Trusted Advisor would also help in ensuring that regulations and contracts that require such compliance are followed, maintaining the optimal amount of security necessary. Third party services such as DataDog or Snyk may also be used as part of this.

Another aspect to be aware about is within how secrets are managed; these must be managed within AWS secrets manager, and not within environmental variables. This way, the variables are not publicly exposed, and a single source of truth is created. Using this also allows for automated scheduled rotation if it is enabled and allows for us to audit secrets easily, which will be imperative given the very split up architecture that is currently present. These secrets can be passed via secret IDs and retrieved using the AWS SDK.

The last aspect to consider is when using different accounts, particularly for deployment. A load pipeline must be created across different accounts based on the functionality and assign specific roles as part of those accounts. This way, security can also be maintained, and a single point of failure is not present, given that a deployment has to go through all the accounts currently used as part of the deployment before being able to go through. Communication can be made through services such as AWS SNS to notify the relevant personnel and services about the changes that currently are in progress.