Origin Access Control (OAC)
和OAI相比，OAC的改进点在于：
- 安全性提高。更频繁的密钥轮换；更多协议的支持，
GET, PUT, POST, PATCH, DELETE, OPTIONS, HEAD - 2022 12月前的region支持OAI，但之后的region都不支持OAI了，只支持OAC
OAC签名选项配置
cloudfront接受到客户端的请求后，如果没有命中缓存，会把请求转发到S3。在转发到S3的时候，会把请求进行签名（SigV4）。
在配置OAC时，有以下三个签名的选项：“Do not sign requests”, “Sign requests”, sign requests but “Do not override authorization header” ：
“Sign requests”
此时cloudfront到S3的每一次请求都将使用SigV4签名，如果S3检查签名不对，则将拒绝请求。在这个配置下，CloudFront将把客户端传过来的Authorization header也重新覆盖掉。
这是aws推荐的配置选项。
“Do not override authorization header”
如果客户端应用可以进行签名操作，则可以使用这个选项
“Do not sign requests” option
这个选项等同于不使用OAC，因为CloudFront不会把签名发往S3. 如果客户端会进行签名或者S3是公开的话，就可以使用这个选项。
在使用默认的Sign requests选项时，要注意如果将客户端的请求头传入到S3,有可能会报以下错误
<Error>
<Code>SignatureDoesNotMatch</Code>
<Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message>
</Error>
因为cloudfront会把sign V4的信息通过请求头的方式传给S3验证，如果客户端的请求头也传入到S3，有可能会引起被覆盖。
参考：https://www.codejam.info/2021/02/cloudfront-s3-signature-does-not-match.html
创建OAC演示
创建Cloudfront时，如果选择S3做为cloudfront的源，需要配置OAI或OAC来授权。
选择创建OAC：
然后全部保持默认即可：
创建完成后，选择copy policy，跳到S3的policy设置页面，加上policy：
policy示例如下：
{
"Version": "2008-10-17",
"Id": "PolicyForCloudFrontPrivateContent",
"Statement": [
{
"Sid": "AllowCloudFrontServicePrincipal",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::airflow-kpf/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::145197526627:distribution/ER32E00BTVMVA"
}
}
}
]
}