the user starts a remote session to the management endpoint with their own credentials, when they get connected, they import the cmdlets they need, they will then run a function that does the work they need to do, and pass in the friendly name of the environment they want to do the work in, along with their own credentials as parameters. So for instance, when a user uses my module to do some work in one of our clients' environments its a pretty cool experience. What is really cool about this, is that you have essentially private data inside of the module that is not exposed to the person calling/using the code at all because of the constraints you have setup. much more granular than any prior solution I have been aware of. The constrained endpoints expose only specific functions from specific modules, and only allow specific parameters, arguments, etc with them, its extremely easy to lock things down in a very granular way. I am building constrained endpoints and powershell modules for various teams to use at our org. I have been working with constrained endpoints for the past few months, getting ready to roll out a new pilot program at our org. The next option is to just give up and switch careers.and no one likes doing that. This is a little better as far as ease of implementation and maintenance, but you still have to trust the people with credentials you eventually have to give them in order for them to be able to do the work. The next option is storing the credentials in a centralized location where you can have control over and insight into who is able to access and use the credentials.
If you have important secrets that are needed to perform tasks, your only real options are either:Ĭreating more constrained credentials that can do said task and only that task, and have users use those credentials to do the task.īut that gets harder to maintain than it should be because of all the accounts you end up with.
0 kommentar(er)
