I have to use SSO to authenticate, which I do via a browser. I run queries with:
$ snowsql -a <ACCOUNT> -u <USERNAME> -r <ROLE> --authenticator externalbrowser -f foo.sql
However, this requires me to do the annoying browser authentication process every time. I know that account/user/role can be put in the config, those are not the problem since I often change all three - but I'd like to avoid having to open/close the browser for SSO auth every time I run a query.
Is there a way to make SnowSQL cache the credentials, so that on repeated runs like this, I don't have to reauthenticate?
Key pair authentication is documented here: https://docs.snowflake.com/en/user-guide/key-pair-auth.html
In my view it is the best solution when using the CLI and you want the authorisation steps to be as minimal as possible
Related
I'm using apparmor as hardening layer for libvirt-qemu , everything is OK , but there is one thing that I can't solve systematically, let me explain :
When create a new qemu instance , profile is generated from /etc/apparmor.d/libvirt/TEMPLATE.qemu to a file with path /etc/apparmor.d/libvirt/libvirt-81303229-df4c-4b18-b33b-277bcda81b0f for example .
When instance is shut-off profile is unloaded from kernel by apparmor and it is OK as expected. But if i remove the instance definitively, i would expect that profile is removed also from filesystem, but it is not and still present in filesystem. After some time I have very big mess in libvirt instance profile files
Yes .. I can write a cron job what will be delete unnecessary libvirt profile files ... but ..is there some more clear solution , maybe builtin function of apparmor ?
Thanks
Are you using libvirt undefine to delete the stopped guest? It appears that virt-aa-helper should delete an undefined domain but I think it is a bug and you should file a ticket.
You can use the virt-aa-helper command directly to remove the files which is probably the safest as it should deal with the dependencies for you.
An example command is:
$ sudo /usr/lib/libvirt/virt-aa-helper -D -u libvirt-3c3d5aa2-f581-457d-b5ab-efbf9fdd4a6e
But it may be some edge case that they need to account for, where you can undefine a running instance to convert it to ephemeral. You would need to take care of that edge case.
Note: Because virt-aa-helper is intended to be run by libvirt you will have to use sudo with the command. If you do not it will silently fail and not remove the profile.
I'm using the mysql image as an example, but the question is generic.
The password used to launch mysqld in docker is not visible in docker ps however it's visible in docker inspect:
sudo docker run --name mysql-5.7.7 -e MYSQL_ROOT_PASSWORD=12345 -d mysql:5.7.7
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b98afde2fab7 mysql:5.7.7 "/entrypoint.sh mysq 6 seconds ago Up 5 seconds 3306/tcp mysql-5.7.7
sudo docker inspect b98afde2fab75ca433c46ba504759c4826fa7ffcbe09c44307c0538007499e2a
"Env": [
"MYSQL_ROOT_PASSWORD=12345",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"MYSQL_MAJOR=5.7",
"MYSQL_VERSION=5.7.7-rc"
]
Is there a way to hide/obfuscate environment parameters passed when launching containers. Alternatively, is it possible to pass sensitive parameters by reference to a file?
Weirdly, I'm just writing an article on this.
I would advise against using environment variables to store secrets, mainly for the reasons Diogo Monica outlines here; they are visible in too many places (linked containers, docker inspect, child processes) and are likely to end up in debug info and issue reports. I don't think using an environment variable file will help mitigate any of these issues, although it would stop values getting saved to your shell history.
Instead, you can pass in your secret in a volume e.g:
$ docker run -v $(pwd)/my-secret-file:/secret-file ....
If you really want to use an environment variable, you could pass it in as a script to be sourced, which would at least hide it from inspect and linked containers (e.g. CMD source /secret-file && /run-my-app).
The main drawback with using a volume is that you run the risk of accidentally checking the file into version control.
A better, but more complicated solution is to get it from a key-value store such as etcd (with crypt), keywhiz or vault.
You say "Alternatively, is it possible to pass sensitive parameters by reference to a file?", extract from the doc http://docs.docker.com/reference/commandline/run/ --env-file=[] Read in a file of environment variables.
Hey all I'm completely new to Unix and I need to write up a "shell script" (?) to connect to another terminal and run a few SQL queries. How on earth do I do this? I've been browsing a few answers from this and other boards and if I have found my answer I don't understand it.
I am able to manually connect, enter password, etc, but I need to automate the process. I don't have access to Perl (as a few answers have suggested) and I am unable to edit the etc/shadow file. So I assume this has to be done strictly through Unix itself. This is what I am currently using:
X=`vUser='USER-NAME'
vPass='PASSWORD'
vTable='TABLENAME'
vHOST='HOST-NAME'
vPORT=4443
ssh root#vHost
expect {
"root#the-host password:"{
send -s "'vPass'\r"
}
}
SQL_Query='select * from vTable limit 10'
mysql -p$vPASS -D$vTable -u$vUser P$vPort<<EOF
$SQL_Query
EOF`
echo $X>Output.dat
Please explain all answers in full. I'm trying to learn.
Might not be a 100% relevant but I had to do the same on Linux.
First off you want to make a new user account on the other server that has SSH access and generate an SSH keypair, even if you're going to do this as root, keypairs are far superior over standard passwords because they're stronger, and they allow you to log in automatically over SSH.
There's no real way of automating the password entry process (at least, not on Linux), hence the reason SSH keys are required to do this.
You can basically send a chain of commands as a parameter to the SSH tool.
Like so,
ssh user#host "ls; cat *; yes;"
Hope that helped.
Try this:
Copy your SSH public key to your clipboard (output of cat ~/.ssh/id_rsa.pub). If you don't have an SSH key pair then generate it with this tutorial.
Paste your public key to your server's ~/.ssh/authorized_keys file. If it doesn't have one, create it with nano ~/.ssh/authorized_keys and paste it there.
In your computer, you can run the script in the server with the following command:
ssh user#server_ip 'bash -s' < local_script.sh
Or if you have a single command to run then this will do:
ssh user#server_ip "echo Test | tee output.log"
If you don't like SSH asking you for the password all the time, use ssh-agent
For SQL-specific scripts, you can put all your SQL commands in a single file, say query.sql. You should copy query.sql to your server (scp query.sql user#server_ip:~/) and then run
ssh user#server_ip "mysql -uyourusername -pyourpassword < query.sql | tee output.log"
The output will be saved in output.log. Check this answer too.
There is a Linux command ssh-copy-id will do this for you, it is also available to Mac as a homebrew formula.
So when I bring up a GCE instance using the standard debian 7 image, and issue a "gsutil config" command, it fails with the following message:
jcortez#master:~$ gsutil config
Failure: No handler was ready to authenticate. 4 handlers were checked. ['ComputeAuth', 'OAuth2Auth', 'OAuth2ServiceAccountAuth', 'HmacAuthV1Handler'] Check your credentials.
I've tried it on the debian 6 and centos instances and had the same results. Issuing "gcutil config" works fine however. I gather I need to set up my ~/.boto file but I'm not sure what to.
What am I doing wrong?
Using service account scopes as E. Anderson mentions is the recommended way to use gsutil on Compute Engine, so the images are configured to get OAuth access tokens from the metadata server in /etc/boto.cfg:
[GoogleCompute]
service_account = default
If you want to manage gsutil config yourself, rename /etc/boto.cfg, and gsutil config should work:
$ sudo mv /etc/boto.cfg /etc/boto.cfg.orig
$ gsutil config
This script will create a boto config file at
/home/<...snipped...>/.boto
containing your credentials, based on your responses to the following questions.
<...snip...>
Are you trying to use a service account to have access to Cloud Storage without needing to enter credentials?
It sounds like gsutil is searching for an OAuth access token with the appropriate scopes and is not finding one. You can ensure that your VM has access to Google Cloud Storage by requesting the storage-rw or storage-full permission when starting your VM via gcutil, or by selecting the appropriate privileges under "Project Access" on the UI console. For gcutil, something like the following should work:
> gcutil addinstance worker-1 \
> --service_account_scopes=https://www.googleapis.com/auth/devstorage.read_write,https://www.googleapis.com/auth/compute.readonly
When you configured your GCE instance, did you set it up with a service account configured? Older versions of gsutil got confused when you attempted to run gsutil config when you already had service account credentials configured.
If you already have a service account configured you shouldn't need to run gsutil config - you should be able to simply run gsutil ls, cp, etc. (it will use credentials located elsewhere than your ~/.boto file).
If you really do want to run gsutil config (e.g., to set up credentials associated with your login identity, rather than service account credentials), you could try downloading the current gsutil from http://storage.googleapis.com/pub/gsutil.tar.gz, unpacking it, and running that copy of gsutil. Note that if you do this, the personal credentials you create by running gsutil config will essentially "hide" your service account credentials (i.e., you would need to move your .boto file aside if you ever want to user your service account credentials again).
Mike Schwartz, Google Cloud Storage team
FYI I'm working on some changes to gsutil now that will handle the problem you encountered more smoothly. That version should be out within the next week or two.
Mike
we've updated hudson to jenkins and have a few dependencies upon the "hudson" user we used to have.
Now that we have jenkins running (works fine) we'd like it to run as the user "hudson" in order to keep our other processes intact without having to rewrite them.
We found instructions on how to do this BEFORE installing jenkins, but we're already past that point. Jenkins is installed and up and running. Is there a way to let jenkins run as the user "hudson"?
We are running CENTOS
Jenkins usually runs with it's own user, so there are two main issues to handle:
Make sure user 'hudson' has full access to the files of user 'jenkins' (or whatever user it was set to run as).
Start the Jenkins-daemon (or other initiator) with the 'hudson' user.
(another approach is to change the user-ID so it is actually the same user but with two names)
Good luck!
If you've installed Jenkins from RPM, there should be an /etc/sysconfig/jenkins file with a JENKINS_USER setting that defaults to 'jenkins' that you can change to 'hudson'.
I second Gonen's comment above about making sure you change the ownership of the 'jenkins' owned files to 'hudson'. Don't forget about the /var/log/jenkins logs.
Also don't forget to restart the Jenkins service after updating the files.