🔐
AWS SCS-C01
  • Practice Test Scores
  • Domain 1 - Incident Response
    • Incident Response
    • Exposed AWS Access Keys
    • Compromised EC2 Instance
    • How do you report abuse of AWS resources?
    • GuardDuty
    • Penetration Testing
  • Domain 2 - Logging & Monitoring
    • Some Basics
    • Inspector
    • Security Hub
    • AWS WAF
    • Systems Manager
    • Systems Manager Features
    • CloudWatch Logs
    • Athena
    • CloudTrail
    • Config
    • Trusted Advisor
    • CloudTrail Log File Integrity
    • Macie
    • S3 Event Notifications
    • VPC Flow Logs
    • Centralized Logging Architecture
  • Domain 3 - Infrastructure Security
    • Bastion Hosts
    • Site-to-Site VPN
    • VPC Peering
    • VPC Endpoints
    • Network ACL
    • Firewall vs IPS vs IDS
    • EBS
    • CloudFront
    • Shield
    • Mitigating DDoS Attacks
    • EC2 Key Pair Troubleshooting
    • EC2 Tenancy
    • Artifact
    • Lambda@Edge
    • Simple Email Service (SES)
    • DNS Support in VPC
  • Domain 4 - Identity & Access Management
    • Organizations
    • IAM Policy Evaluation Logic
    • Understanding IAM Policies
    • IAM Tutorial: Delegate access across AWS accounts using IAM roles
    • External ID
    • iptables
    • IAM policy elements: Version
    • IAM policy elements: Variables and tags
    • Policy elements: Principal and NotPrincipal
    • IAM policy elements: Condition
    • Security Token Service (STS)
    • Identity federation in AWS
    • Enabling SAML for your AWS resources
    • Single Sign-On
    • Cognito
    • Directory Service
    • Trusts in Active Directory
    • Example S3 Bucket Policies
    • Cross-account access to S3 buckets using Resource-based policies and IAM policies
    • S3 Access Control Lists (ACLs)
    • Presigned URLs
    • S3 Versioning
    • S3 Cross-Region Replication (CRR)
    • S3 Object Lock
    • Configuring MFA-protected API access
    • IAM Permission Boundaries
  • Domain 5 - Data Protection
  • CloudHSM
  • Key Management Service (KMS)
  • Symmetric CMKs vs Asymmetric CMKs
  • Data Key Caching
  • Deleting KMS CMKs
  • Default KMS Key Policy
  • Managing access to KMS CMKs
  • KMS CMK Key Types
  • Rotating KMS CMKs
  • Example Key Policies for KMS Questions
  • KMS Grants
  • KMS CLI Commands
  • Importing key material in KMS
  • KMS Condition Keys
  • Migrating Encrypted KMS Data Across Regions
  • KMS Encryption Context
  • CloudHSM vs KMS
  • S3 Data Encryption
  • Application Load Balancer (ALB)
  • ELB Listeners Part 1
  • ELB Listeners Part 2
  • AWS Certificate Manager (ACM)
  • Glacier
  • DynamoDB Encryption
  • AWS Secrets Manager
  • Summaries
    • Domain 1
    • Domain 2
    • Domain 3
    • Domain 4
    • Domain 5
Powered by GitBook
On this page
  • kms:ViaService
  • kms:GranteePrincipal

Was this helpful?

KMS Condition Keys

  • KMS provides an additional set of predefined condition keys that you can use in key policies and IAM policies.

  • These condition keys are specific to KMS.

  • For example, you can use the kms:EncryptionContext condition key to require a particular encryption context when controlling access to a KMS CMK.

kms:ViaService

  • It limits use of an KMS CMK to requests from specified AWS services.

  • You can specify one or more services in each kms:ViaService condition key.

  • All AWS managed CMKs use a kms:ViaService condition key in their key policy document.

    • This condition allows the CMK to be used only for requests that come from the service that created the CMK.

  • For example, the following statement from a key policy uses the kms:ViaService condition key to allow a customer managed CMK to be used for the encryption and decryption only when the request comes from EC2 or RDS in the US West (Oregon) region on behalf of ExampleUser:

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:user/ExampleUser"
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": [
        "ec2.us-west-2.amazonaws.com",
        "rds.us-west-2.amazonaws.com"
      ]
    }
  }
}
  • You can also use a kms:ViaService condition key to deny permission to use a CMK when the request comes from particular services.

  • For example, the following policy statement from a key policy uses a kms:ViaService condition key to prevent a customer managed CMK from being used for Encrypt operations when the request comes from Lambda on behalf of ExampleUser:

{
  "Effect": "Deny",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:user/ExampleUser"
  },
  "Action": [
    "kms:Encrypt"    
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": [
          "lambda.us-west-2.amazonaws.com"
      ]
    }
  }
}

kms:GranteePrincipal

  • You can use this condition key to control access to the CreateGrant operation based on the value of the GranteePrincipal parameter in the request.

  • The following example policy statement uses the kms:GranteePrincipal condition key to allow a user to create grants for a CMK only when the grantee principal in the grant is the LimitedAdminRole.

{
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:user/ExampleUser"
  },
  "Action": "kms:CreateGrant",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:GranteePrincipal": "arn:aws:iam::111122223333:role/LimitedAdminRole"
    }
  }
}
PreviousImporting key material in KMSNextMigrating Encrypted KMS Data Across Regions

Last updated 4 years ago

Was this helpful?