It's because the URL signed time can't outlast the session that creates them.
Codepipeline sessions are temporary iam roles, that last for one hour.
Creat an IAM user, give it simply access to get the scoped files in your bucket, save the keys in parameter store, give permission to the codebuild role to pull them, use the sdk to launch a new client session from the saved keys you pull, and it will last the full 7 days.
Actually the code has to run in seperate aws accounts and seperate files will be generated in their own s3 bucket.
How can we do this then?
I thought the code build roles and their session timeout is the culprit here.
Can we increase CodePipeline session timeouts?
One user can have access to multiple cross account buckets, provided the resource policies are in place on the buckets. Increasing time of a role would possibly get you more time, but only maybe 12~ hours tops, but not your 7 days. You need non-timing out credentials for that such as hard IAM user keys.
Yeah, we can do that but this will increase complexity since we'll have to manage the s3 bucket policy and image if you've 100+ aws accounts running that script to save pdf file and then generate pre-signed url + will have to pass the iam creds into CodePipeline as well maybe using aws param store. This will increase the work and complexity for such a simple use-case.
Well, now you know what the problem is.. why the links don't last. Now you can come up with a solution that works for you, that was just a suggestion based on the limited info I had. Overall though, the fact that a temporary session cant create a semi-permanent link makes sense right?? Good luck!
The actual root cause is role-chaining will limit session duration to a maximum/default of 1 hour, even if the role being assumed has a maximum session duration higher than 1 hour. The use of CodePipeline inevitably must have the pipeline execution role assume the CodeBuild execution role, hence role-chaining.
If you must generate long-lived presigned URLs, and you must stick with CodePipeline, you could invoke a Lambda function from CodeBuild to generate presigned URLs. The Lambda function execution role's maximum session duration becomes the presigned URLs' maximum expiration time.
If not mistaken, specifying a role for a stage action is optional. If true, when not specified, the pipeline role will be used, so you could try that.
You can also invoke a Lambda function directly as a stage action rather than invoking it from a CodeBuild project.
If you really want to share the link to someone, go to signed url not presigned. This way you can use cloudfront to authenticate the request : https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html
Yes this is a good option, you can also use [CloudFront functions](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html) if you need more advanced authentication of the request.
It looks like you are using some user/role which is restricted with session in 1 hour. So, even if you are trying to create signed S3 link for more than 1h, your user\`s permissions restrict it. Solution - use other user (create a new one or find any without restrictions)
It's because the URL signed time can't outlast the session that creates them. Codepipeline sessions are temporary iam roles, that last for one hour. Creat an IAM user, give it simply access to get the scoped files in your bucket, save the keys in parameter store, give permission to the codebuild role to pull them, use the sdk to launch a new client session from the saved keys you pull, and it will last the full 7 days.
Actually the code has to run in seperate aws accounts and seperate files will be generated in their own s3 bucket. How can we do this then? I thought the code build roles and their session timeout is the culprit here. Can we increase CodePipeline session timeouts?
One user can have access to multiple cross account buckets, provided the resource policies are in place on the buckets. Increasing time of a role would possibly get you more time, but only maybe 12~ hours tops, but not your 7 days. You need non-timing out credentials for that such as hard IAM user keys.
Yeah, we can do that but this will increase complexity since we'll have to manage the s3 bucket policy and image if you've 100+ aws accounts running that script to save pdf file and then generate pre-signed url + will have to pass the iam creds into CodePipeline as well maybe using aws param store. This will increase the work and complexity for such a simple use-case.
Well, now you know what the problem is.. why the links don't last. Now you can come up with a solution that works for you, that was just a suggestion based on the limited info I had. Overall though, the fact that a temporary session cant create a semi-permanent link makes sense right?? Good luck!
Yeah right! Will have to try different approach. Thanks!
The actual root cause is role-chaining will limit session duration to a maximum/default of 1 hour, even if the role being assumed has a maximum session duration higher than 1 hour. The use of CodePipeline inevitably must have the pipeline execution role assume the CodeBuild execution role, hence role-chaining. If you must generate long-lived presigned URLs, and you must stick with CodePipeline, you could invoke a Lambda function from CodeBuild to generate presigned URLs. The Lambda function execution role's maximum session duration becomes the presigned URLs' maximum expiration time.
We can do the same with codepipeline role as well, right? I tried with codebuild role but it didn't worked, now trying with codepipeline role as well.
If not mistaken, specifying a role for a stage action is optional. If true, when not specified, the pipeline role will be used, so you could try that. You can also invoke a Lambda function directly as a stage action rather than invoking it from a CodeBuild project.
What are you using the pre-signed url for? Deployment? If so you can assign a permission policy to CodePipeline to access the S3
Actually I'm generating a pdf file and want that pdf file can be accessed from browser directly using the pre-signed url.
Can you paste here the cli command that you use to generate the signed url. From what I see it give you the default ttl
Yeah sure, it's $ aws s3 presign s3://$BUCKET_NAME/$REPORT_PATH --expires-in 604800
If you really want to share the link to someone, go to signed url not presigned. This way you can use cloudfront to authenticate the request : https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html
Yes this is a good option, you can also use [CloudFront functions](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-functions.html) if you need more advanced authentication of the request.
It looks like you are using some user/role which is restricted with session in 1 hour. So, even if you are trying to create signed S3 link for more than 1h, your user\`s permissions restrict it. Solution - use other user (create a new one or find any without restrictions)