S3 Architecture and Features Flashcards
How do Permissions work in S3?
o Bucket authorisation within S3 is controlled using identity policies on AWS identities, as well as bucket policies in the form of resource policies on the bucket and bucket or object ACLs (Legacy method, not recommended)
o Final authorisation is a combination of all applicable policies
o Priority order is (1) Explicit Deny, (2) Explicit Allow, (3) Implicit Deny
o Note: The bucket, at creation, only trusts the account that created it
o Identity policies attached to IAM users, roles or groups can include S3 elements; this only works for identities in the same account as the bucket
o To give access to identities outside the account, or public access, bucket policies can be used (= resource policies applied to S3 buckets)
How can data be transferred to an S3 bucket?
o Uploads to S3 are generally done using the S3 console, the CLI, or directly using the APIs.
o Uploads either use a single operation (single PUT upload) or multipart uploads
o Single PUT Uploads: limit is 5Gb, can cause performance issues, if the upload fails the whole upload fails
o Multipart Uploads: An object is broken into parts (up to 10,000), each part is 5Mb to 5Gb, and the last part can be less. Faster (because of parallel uploads), handle individual fails, recommended for anything above 100Mb
How does encryption work in S3?
o Data between a Client and S3 is encrypted in transit using SSL. Encryption at rest can be configured on a per-object basis, and is off by default
o Client-side encryption: The client/application is responsible for managing the encryption/decryption process and its keys. Only used when strict security compliance is required, as it has significant admin and processing overhead
o Server-Side Encryption with Customer-Managed Keys (SSE-C): S3 handles the E/D process, customer manages the keys, that have to be provided at every PUT/GET request
o Server-Side Encryption with S3-Managed Keys (SSE-S3): Objects are E using AES-256 by S3. The keys are generated by S3, using KMS on your behalf. Keys are stored with objects in an encrypted form. If you have permission on the object, then you can decrypt and access it. No role separation (S3 doing all)
o Server-Side Encryption with AWS KMS-Managed Keys (SSE-KMS): Objects are E using individual keys generated by KMS. Encrypted keys are stored with the E objects; D of an object needs both S3 and KMS key permission (role separation)
o Bucket Default Encryption: Objects are E in S3, not buckets. Each PUT operation needs to specify E (and type) or not. A bucket default captures any PUT operations where no encryption method/directive is specified. It does not enforce what type can and cannot be used. Bucket policies can enforce
How does S3 support Static Websites?
o S3 buckets can be configured to host websites. Content can be uploaded to the bucket and when enabled, static web hosting will provide a unique endpoint URL that can be accesses by any web browser.
o S3 buckets can host HTML, CSS, JavaScript, Media (audio, movies, images)
o S3 can be used to host front-end code for serverless applications or an offload location for static content.
o CloudFront can also be added to improve the speed and efficiency of content delivery for global users, or add SSL for custom domains
o Route 53 and alias records can be used to add human-friendly names to buckets
What is CORS?
o Cross-Origin Resource Sharing (CORS): it is a security measure that allows web application running in one domain to reference resources in another
How does Object Versioning work, what is MFA Delete?
o Versioning can be enabled on an S3 bucket. Once enabled, any operation that would otherwise modify objects generates instead new versions of that object
o Once a bucket is version-enabled, it can never be fully switched off, only suspended
o With versioning enabled, and AWS account is billed for all versions of all objects. Object deletions by default do not delete an object, only places a marker to indicate the object is deleted (operation that can be undone)
o MFA Delete is a feature designed to prevent accidental deletion of objects. Once enabled, a one-time password is required to delete an object version or when changing the versioning state of a bucket
What are Presigned URLs, and what are the most common use cases and error scenarios?
o A Presigned URL can be created by an identity in AWS, providing access to an object using the creator’s access permission
o When the presigned URL is used, AWS verifies the creator’s access to the object, not yours. The URL is encoded with authentication built in and has an expiry time
o Presigned URLs can be used to download or upload objects
o Any identity can create a presigned URL, even one that doesn’t have access to the object
o Common scenarios:
Stock images website – media stored privately on S3, presigned URL generated when an image is purchased
Client access to upload an image for process to an S3 bucket
o Common error situation:
Presigned URL has expired – 7 days maximum
Permissions of the creator of the URL have changed
URL was created using a role (36-hour max) and the role’s temporary credentials have expired (aim to never create presigned URLs using roles)