2 docs tagged with "versioning"

This module creates an S3 bucket with support for versioning, lifecycles, object locks, replication, encryption, ACL, bucket object policies, and static website hosting. For backward compatibility, it sets the S3 bucket ACL to `private` and the `s3_object_ownership` to `ObjectWriter`. Moving forward, setting `s3_object_ownership` to `BucketOwnerEnforced` is recommended, and doing so automatically disables the ACL. This module blocks public access to the bucket by default. See `block_public_acls`, `block_public_policy`, `ignore_public_acls`, and `restrict_public_buckets` to change the settings. See [AWS documentation](https://docs.aws.amazon.com/AmazonS3/latest/dev/access-control-block-public-access.html) for more details. This module can optionally create an IAM User with access to the S3 bucket. This is inherently insecure in that to enable anyone to become the User, access keys must be generated, and anything generated by Terraform is stored unencrypted in the Terraform state. See the [Terraform documentation](https://www.terraform.io/docs/state/sensitive-data.html) for more details The best way to grant access to the bucket is to grant one or more IAM Roles access to the bucket via `privileged_principal_arns`. This IAM Role can be assumed by EC2 instances via their Instance Profile, or Kubernetes (EKS) services using [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). Entities outside of AWS can assume the Role via [OIDC](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html). (See [this example of connecting GitHub](https://aws.amazon.com/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/) to enable GitHub actions to assume AWS IAM roles, or use [this Cloud Posse component](https://github.com/cloudposse/terraform-aws-components/tree/main/modules/github-oidc-provider) if you are already using the Cloud Posse reference architecture.) If neither of those approaches work, then as a last resort you can set `user_enabled = true` and this module will provision a basic IAM user with permissions to access the bucket. We do not recommend creating IAM users this way for any other purpose. If an IAM user is created, the IAM user name is constructed using [terraform-null-label](https://github.com/cloudposse/terraform-null-label) and some input is required. The simplest input is `name`. By default the name will be converted to lower case and all non-alphanumeric characters except for hyphen will be removed. See the documentation for `terraform-null-label` to learn how to override these defaults if desired. If an AWS Access Key is created, it is stored either in SSM Parameter Store or is provided as a module output, but not both. Using SSM Parameter Store is recommended because that will keep the secret from being easily accessible via Terraform remote state lookup, but the key will still be stored unencrypted in the Terraform state in any case.

This module creates an S3 bucket suitable for receiving logs from other `AWS` services such as `S3`, `CloudFront`, and `CloudTrails`. This module implements a configurable log retention policy, which allows you to efficiently manage logs across different storage classes (_e.g._ `Glacier`) and ultimately expire the data altogether. It enables [default server-side encryption](https://docs.aws.amazon.com/AmazonS3/latest/userguide/bucket-encryption.html). It [blocks public access to the bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html) by default. As of March, 2022, this module is primarily a wrapper around our [s3-bucket](https://github.com/cloudposse/terraform-aws-s3-bucket) module, with some options preconfigured and SQS notifications added. If it does not exactly suit your needs, you may want to use the `s3-bucket` module directly. As of version 1.0 of this module, most of the inputs are marked `nullable = false`, meaning you can pass in `null` and get the default value rather than having the input be actually set to `null`. This is technically a breaking change from previous versions, but since `null` was not a valid value for most of these variables, we are not considering it a truly breaking change. However, be mindful that the behavior of inputs set to `null` may change in the future, so we recommend setting them to the desired value explicitly.