At Reyki AI, security is our highest priority. We take painstaking measures to ensure that our customers’ infrastructure is never compromised by operating on the least privilege principle. At every stage of the process, we ensure that we utilize only the minimal permissions needed to operate our software.
Cross-Account Role
During the onboarding process, Reyki will ask you to create cross-account roles that enable us to access your AWS account with the minimum set of permissions we need to operate our software.
In a normal IAM role, an IAM user assumes an AWS identity with an access policy that determines the scope of the actions allowed to be taken by that user. For example, if a user assumes an IAM role with an access policy that only allows for “Describe” actions on EC2 services, that user will only be able to fetch metadata about the account’s EC2 instances. They will be blocked from modifying, creating, or deleting EC2 instances. Typically, these IAM roles are assumed by IAM users within the existing AWS account.
In a cross-account role, a user from an external AWS account assumes the role of an IAM user with the attached access policy in a different AWS account. These roles are administered through a trust policy that explicitly grants this permission:
Reyki retrieves and stores cost and usage metadata through the permissions granted by the Cross-Account Roles. Specifically, we store the following:
All spend and savings data dating back to 1 year for the read-only dashboard.
All spend and savings data starting from the date the customer joins the Reyki organization.
Reserved instance and savings plan information, including spend commitments and utilization.
EC2 metadata, including region, instance type and family, platform, and purchase type.
All data is deleted when a customer deactivates their account in compliance with GDPR regulations.
AWS Organization Security Principles
In general, we follow the best practices recommended by AWS Well-Architected Framework to ensure the security of our AWS Organization. These principles include the following:
Our AWS root account is never accessed; we only interact with the organization through IAM accounts.
Our root account requires hardware MFA to gain access.
All IAM user accounts have multi-factor authentication enabled and are assigned roles based on the principle of least functionality.
No Service Control Policies affecting member accounts are implemented, so there is no risk of blocking access to resources for any of our child accounts.
We've enabled AWS GuardDuty for all available services (S3, EKS, EC2, RDS, Lambda).