k9 Architecture

k9 Access Capability Model

Motivation to Create Our Own Model

We created our own access capability model instead of using AWS’ model, and that warrants an explanation.  Both models categorize the many individual AWS API actions to a small set of categories to make them easier to think about.  The core AWS access levels for service API’s are List, Read, Write, and Permissions Management. Services that manage resources such may have another access level named Tagging. AWS classifies each API action to exactly one of these five access levels. The AWS access level model has three problems which makes understanding access capabilities at scale difficult. 

First, similar API actions are categorized inconsistently or less than conservatively from a security perspective. Let’s try to determine a user’s permissions based on the S3 API actions the user is allowed to call. Full List access to S3 grants permission to call ListAllMyBuckets, but it does not grant permission to call ListAccessPoints because ListAccessPoints is classified as an S3 Read action. Do you know how GetObject and DescribeJob are classified? More importantly, is it accurate to say that a user with full Read access to a service has higher privileges than a user with full List access to the same service?

Second, an API action may be categorized in one and only one access level, even when that action belongs in multiple. The RDS API action named DeleteDBCluster presents another interesting case. AWS has classified this action as Write access. Do you expect users with Write access to be able to delete data or resources? We do not. This should serve as an example that the AWS access model stifles an engineer’s ability to identify gaps in security. 

Third, the AWS access level model is missing a couple categories that provide helpful precision and distinction for security analysis.  For example, there is not a way to distinguish between control plane operations that administer the service and data plane operations affecting resources or data managed by the service.  That is, the AWS access levels do not distinguish between creating an S3 bucket and writing to that bucket.  Both actions have the Write access level.  The AWS model also does not provide a way to identify delete operations clearly.

k9 sought to create a API access capability model better-suited to security engineering. 

The k9 access capability model has six levels: read-data, write-data, delete-data, use-resource, administer-resource, and unclassified access. By defining these capabilities and mapping API actions to all applicable capabilities, cloud engineers determine who has access to what, quickly and confidently.

k9’s access capability model is more a precise, accurate, and informative representation of API access than AWS’ access level model for security engineering. Now we can distinguish between data and resource definition as well as classify each API action using multiple levels. By eliminating the constraint to shoehorn an action into a misrepresentative label, k9 will not express a false negative thereby more accurately presenting the security posture of an account to the engineer.

Making the AWS Access Model Comprehensible

AWS offers more than 150 services that have more than 10,000 distinct API actions. Reporting the full set of API actions a principal can take on a resource is unlikely to be useful to Security, Compliance, and Application teams. The burden of understanding and summarizing what that access means would fall to them and the report would likely drown them in data. This is especially true for interactions between capabilities that might, e.g. allow a principal to escalate privileges and change a security policy.

k9 summarizes each IAM user or role’s provisioned access to AWS resources into a small number of access capabilities:

  • administer-resource – principal may execute one or more AWS api actions that administer an AWS resource with create, modify, or destroy actions or the security controls for that resource, e.g. modify bucket policies, create RDS cluster
  • read-config – principal has the ability to read service or resource configuration metadata, e.g. the names of database clusters, the number of instances in those clusters, a security policy
  • use-resource – a generic capability indicating that the principal has the ability to use a resource, but the resource manages its access control internally, e.g. rds-db:connect
  • read-data – principal has the ability to read data from the resource, e.g. read objects from an S3 bucket or DynamoDB table
  • write-data – principal has the ability to write data in the resource, e.g. put objects into an S3 bucket or DynamoDB table
  • delete-data – principal has the ability to delete data from the resource, e.g. delete objects in an S3 bucket or items from a DynamoDB table
  • unclassified-access – an internal classification indicating access has not been classified by k9 yet; the k9 delivery process enforces that all service actions are classified

Certain actions may classify to multiple capabilities.  This occurs frequently in data services that involve a cluster of machines.  For example, the rds:DeleteDBCluster action classifies to both delete-data and administer-resource because deleting the DB cluster:

  1. destroys the cluster’s data volume and automated backups, rendering all cluster data unrecoverable
  2. terminates the database cluster instances and endpoints, which are otherwise replaceable

Here are an excerpt from the S3 mappings to give you a broader sense of how the mapping of AWS API actions to k9 capabilities works:

Capability
Service
API Action(s)
read-data S3 s3:ListBucket, s3:GetObject, s3:GetObjectAcl, s3:GetObjectLegalHold, s3:GetObjectRetention, s3:GetObjectTagging, s3:GetObjectTorrent, s3:GetObjectVersion, s3:GetObjectVersionAcl, s3:GetObjectVersionTagging, s3:GetObjectVersionTorrent, s3:ListMultipartUploadParts
write-data S3 s3:AbortMultipartUpload, s3:PutObject, s3:PutObjectTagging, s3:PutObjectVersionAcl, s3:PutObjectVersionTagging, s3:RestoreObject
delete-data S3 s3:DeleteObject, s3:DeleteObjectVersion


The k9 access inventory report clearly identifies which AWS IAM principals have access to what AWS services and resources in terms of these k9 access capabilities.  For example, here is an excerpt for the continuous integration (ci) user in a sandbox account: 

Notice how the ci user has full access to the KMS, RDS, RDS Data, RDS DB, and S3 service APIs as well as full access to a number of specific S3 buckets.  This user is definitely one where engineers would want to review its access.  In particular, it may not make sense for a continuous integration user to be able to delete-data, even though it may need broad privileges to administer resources.

Contact Us

Please contact us and we’ll be happy to answer any questions you may have.