11/29/2023 0 Comments Blanket bastion part 2![]() In other words, he either already had access to the remote server to do this – using means other than the bastion – or somebody who had access to the remote server accepted the addition of his key. If someone adds themself a personal access to the remote server, it will only work if his personal egress public key has already been installed on the remote server. It sounds like a security hole, but it’s not. This allows anyone to grant themselves personal accesses on the bastion, without having to ask anyone else to do it. This is a perfectly valid way to handle accesses on a simple level, without too many users and a limited number of machines. The first way mimics how you would manage accesses if you weren’t using an SSH bastion at all. Depending on your use case – and the level of autonomy you want to give to the teams – there are two ways of managing these personal accesses. ![]() The user can retrieve the corresponding public key at any time, and install it – or get it installed – on the remote servers he needs to access. The account user has no way to see it, or export it out of the bastion, but they can use it through the bastion’s code logic. The personal egress private key sits in the bastion account home. These beasts are generated when the account is first created. On the bastion, each account has (at least) one set of personal egress keys. There are two compatible accesses models on the bastion: personal and group-based. ![]() We’ve previously found that the bastion is not your usual SSH jumphost (in fact, we found it is not a jumphost at all) and we discussed how the delegation was one of the core features we’d originally needed. This is the second part of a blog series, here is part one.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |