Dpl: Feasability of Supporting AWS AssumeRole
I recently discovered the dpl tool and am loving the Travis-AWS integration. One sticking point is the current dependency on hard coded access keys in the .travis.yml file. Encryption helps for protecting the confidentiality of the keys, yet still leaves the problem of long lived keys potentially in many repositories. It would be wonderful if this could support assuming an AWS IAM role in the destination account, allowing users to remove the keys from their yaml files.
The tricky part is this would require having a Travis IAM user to to which assume role permissions could be granted. Has there been any thought to potentially supporting such a scenario? Much appreciate it!
davidski
All 3 comments
I have been asking why this doesn't exist and will be looking for an offering that has it.
Ideally, a role would be created by the CI subsystem for each new repository (I'll call that rH [role of hoster]). Perhaps only generated upon checking a box or whatnot. The ARN for that role, controlled by the CI hoster/provider, could be provided such that we could establish our own IAM role (rO [role of owner]) with which to establish a trust relationship to rH and assign the rights required to take the actions that the CI host will take on our behalf (i.e. as specified within .travis.yml). The agents running under some broad rights and with some secret or another, would assume the rH associated with the repository and this would give it the right to assume rO and to offer those credentials in the environment while executing any necessary privileged actions using them.
This would make a lot of people sleep better at night while providing a strictly superior developer experience and a more secure means of rights management.
erikerikson
on 18 May 2017
Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues
![stale[bot] picture](https://avatars.githubusercontent.com/in/1724?v=4&s=40)
stale[bot]
on 12 Apr 2018
We really need this feature.
hirenshah005
on 9 Jul 2021
Related issues
DanTup
路
5Comments
Sytten
路
4Comments
jyasskin
路
3Comments
davydany
路
5Comments
dmcinnes
路
4Comments
Most helpful comment
I have been asking why this doesn't exist and will be looking for an offering that has it.
Ideally, a role would be created by the CI subsystem for each new repository (I'll call that
rH[role of hoster]). Perhaps only generated upon checking a box or whatnot. The ARN for that role, controlled by the CI hoster/provider, could be provided such that we could establish our own IAM role (rO[role of owner]) with which to establish a trust relationship torHand assign the rights required to take the actions that the CI host will take on our behalf (i.e. as specified within.travis.yml). The agents running under some broad rights and with some secret or another, would assume therHassociated with the repository and this would give it the right to assumerOand to offer those credentials in the environment while executing any necessary privileged actions using them.This would make a lot of people sleep better at night while providing a strictly superior developer experience and a more secure means of rights management.