I am running a RStudio docker container in Azure Apps that requires Single Sign On to access. I can write to a database, but need to know the user who made the write, which is based on the SSO username.
Is there a way to extract this info in a live session?
I tried running Sys.getenv() and viewing under USER, but the result it rstudio
I also tried searching /usr/bin/env but did not find anything there.
Can anyone offer any possible solutions?
Related
I need to achieve to get an user actively logged into several windows virtual machines from a docker alpine container. I can't use remote desktop, as I have no GUI. I also don't think to really control the Virtual Machines at all, I just need a local user of the virtual machines to be logged in.
How do I achieve that without overcomplicating stuff?
For everyone reading this in the future:
I just activated the autologin feature of Windows 10. In that way, I ensure that my machine always automatically logs in with provided credentials.
To acieve that do the following steps:
Open your registry editor
Navigate to the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon
If one of the following doesnt exist, just create them:
Edit "DefaultUserName" to the user you want automatcally to log in
Edit "DefaultPassword" to the password of the user you want to log in
Edit "AutoAdminLogon" and change value from 0 to 1
Restart your computer
We deployed a rails app in Google Cloud Run using their managed platform. The app is working fine and it is able to serve requests.
Now we want to get access to the rails console of the deployed app. Can anyone suggest a way to achieve this?
I'm aware that currently, Cloud Run supports only HTTP requests. If no other way is possible I'll have to consider something like rails web console
I think you cannot.
I'm familiar with Cloud Run but I'm not familiar with rails.
I assume you'd need to be able to shell into a container in order to be able to run IRB. Generally, you'd do this by asking the runtime (Docker Engine, Kubernetes, Cloud Run) to connect you to the container so that you could do this.
Cloud Run does not (appear) to permit this. I think it's a potentially useful feature request for the service. For those containers that contain shells, this would be the equivalent of GCE's gcloud compute ssh.
Importantly, your app may be serviced by multiple, load-balanced containers and so you'd want to be able to console into any of these.
However, you may wish to consider alternatives mechanisms for managing your app: monitoring, logging, trace etc. These mechanisms should provide you with sufficient insight into your app's state. Errant container instances should be terminated.
This follows the concept of "pets vs. cattle" whereby, instead of nurturing individual containers (is one failing?), you nurture the containers holistically (is the service comprising many containers failing?)
For completeness, if you think that there's an issue with a container image that you're unable to resolve through other means, you could run the image elsewhere (e.g. locally) where you can use IRB. Since the same container image will behave consistently wherever it's run, you should be able to observe the issue using IRB locally too.
On my windows server 2016, I am trying to figure out the run command syntax to run a docker image as a user in my ldap. I read this article, but I am not following it very well (different environments)
Perhaps I am miss understanding the concept all together, but in the end I need to run the container as a specific user in our active directory.
Any links to a well documented run --user examples would be appreciated...
One of the things that is confusing is trying to figure out the UserId and such...
The answer depends on the use case, but may be gMSA authentication would help? Basically, with gMSA authentication, you can add the host OS to an AD domain, and containers running on it can share the privileges to use things like network drive. That way, you don't need to pass credential every time you access them.
MS team has a good write up on it here:
Active Directory Service Accounts for Windows Containers
https://learn.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/manage-serviceaccounts
Also, artisticcheese has fantastic walk through.
Enabling integrated Windows Authentication in windows docker container
https://artisticcheese.wordpress.com/2017/09/09/enabling-integrated-windows-authentication-in-windows-docker-container/
Hope this helps.
I am using a Docker image to run cassandra with the lucene plugin: https://hub.docker.com/r/cpelka/cassandra-lucene/
I am running this image on the Google container engine.
Everything works fine, except the user management. When I log in with the cassandra/cassandra user, it seems to have no rights. I cannot list users, and I cannot change passwords.
I can access and edit tables fine though, it just does not seem to be a superuser.
Something I read is that I have to enable password auth. I added the setting to my cassandra.yaml, but I cannot restart my cassandra service. Hell, if I run service cassandra stop, it takes a while and stops, and then I can still connect to my DB remotely. I think the docker image runs the Database in ways that I do not understand with my one day of cassandra experience. Any help is appreciated.
Thanks and good day,
Dries
I have a Powershell script that uploads audit logs to an S3 repository. The script works fine when I run it while logged in but I need to define a scheduled task and the task needs to be run as SYSTEM user. Can someone recommend a way that I can provide the SYSTEM user with the AWS credentials so that they are not stored on the machine in clear text?
I just found what I think is the answer: if I run the script thru the task scheduler once with the 'Set-AWSCredentials' command it creates the encrypted key info in C:\Windows\System32\config\systemprofile\AppData\Local\AWSToolkit\RegisteredAccounts.json. Then I was able to remove the 'Set-AWSCredentials' command and the script seems to run successfully.
I don't believe this is possible. Your authentication info will have to be stored in the clear on the client machine one way or another, and windows doesn't provide any convenient methods for protecting that information.
You might find it more convenient to manage access if you use ssh + encryption certificates as credentials (i believe there's an ssh client for powershell, though i haven't tried using it for aws work)