I do not want to be too broad but I'm using several 3rd party GitHub actions consuming private ssh keys, such as:
scp-action
ssh-action
In this post, I've read:
There are a few community actions that allow you to use rsync or scp,
but what I totally dislike about them is that they usually run some
privately managed Docker containers and I refuse to feed them with my
ssh keys or even passwords.
AFAIK, If 3rd party actions are run in private environments in GH, ssh keys shouldn't be compromised. The only risk I see is if those actions hide nasty pieces of code. But this "risk" holds for all 3rd party software dealing with privata data.
Am I right or passing ssh keys to GH actions is unsafe?
A possible mitigation for the "I refuse to feed them with my ssh keys or even passwords" issue is rotation.
You have actions like:
Rotate AWS Access token stored in Github Repository secrets
AWS Credential Rotary
Secrets Sync Action
...
They are all meant to regularly rotate "secrets", in order to minimize the impact of one of them being compromised.
Related
So, I am new to the GitLab server. Now, what I want to achieve is this:
Allow access to repositories only on certain ssh-keys. There are a limited no of machines and a limited no of users, so if a user adds an ssh-key outside these sets of keys, the repo should not clone there. Because my team size is small, I am okay if I only add those public keys to the account.
I am fine with the idea of ssh access but currently, as an admin, I lose the freedom to conveniently track or choose which all ssh-keys can access my repo. Can I disable users from adding ssh keys?
Is there any other way to ensure this? Would instead of having ssh enabled access HTTPS with whitelisting IP-enabled access work?
GitLab was, in the beginning (2011) based upon gitolite, but switched to its own mechanism in 2013.
Nowadays, it is best to declare a GitLab project private and add users to said project: that way you won't have to manage SSH or HTTPS access: any user who is not part of that project won't be able to see it/clone it (HTTPS or SSH).
In other words, repository access is no longer based on SSH keys (not for years), but is based on project visibility.
The OP adds:
even if a user is part of a project, he should only be able to clone the project on certain remote machines.
That is not a Git or GitLab feature, which means you need:
to restrict Git protocols on GitLab to SSH only
change the gitlab-shell SSH forced command script in order to allow commands only coming from some IPs
There is access to group by IP address restriction feature, since GitLab 12.0 (June 2019), but... only in GitLab Ultimate (meaning: "not free").
I read the question: How does the GitHub authentification work? and https://unix.stackexchange.com/questions/315615/is-ssh-public-key-associated-with-a-user Which is exactly what I am wondering. I am still missing a better answer.
When I test my SSH-key-pair I connect to user git#gitlab.com. My stored Public key has a fingerprint of base64. When the SSH Client(me) want to connect to the server(My gitlab/github account server) it sends its ID(fingerprint), the server checks it ".ssh/authorised_keys" and loops through the Fingerprints after the correct public key to encrypt the challenge.
On Github/Gitlab there are several thousand of users, they all use the same username ("git") to initiate a web (SaaS)session. So how is this separated on the server? I don't get root access on gitlab/github, of course. I only get access to my account though the generic user-session git#gitlab.com. But how is this implemented?
When I use SSH in other situations I have a specific username which I use to [my-username]#router.com
E.g.
If I would set up my own GitLab on a local NAS/Server. How can I create an account (User#local-gitlab.com) but the access rights are limited to the Fingerprint of the differents users SSH-key-pairs?
User: ID:001
User: ID:002
User: ID:003
Somehow I need to limit the access for ID:001 when he/she initiate a ssh-session with my server on account "User".
I can't speak for GitLab, but for GitHub, there is a dedicated service that terminates these connections, contacts the authentication service with the key in question, and then receives the response about whether the user is allowed to access that repo, and if so, contacts the servers storing the data.
GitHub has more than 65 million users, many users have multiple SSH keys, and there are also deploy keys for servers, so using the command directive with an OpenSSH authorized_keys file would be extremely slow, since it would involved parsing and reading probably gigabytes of data each time a connection was made.
If you need this yourself for a small set of users, the command directive in authorized_keys is a viable approach. If you need something more scalable, you can create a custom server with something like libssh and perform authentication yourself, either in that process, or in a separate process.
I found this question+answer: https://security.stackexchange.com/questions/34216/how-to-secure-ssh-such-that-multiple-users-can-log-in-to-one-account. Which highlights that you can put restrictions on authorised_keys. Don't know if that provides precise answer for my question, but it looks like it.
command="/usr/local/bin/restricted-app",from="192.0.2.0/24",no-agent-forwarding,no-port-forwarding,no-x11-forwarding ssh-rsa AAAA… git#gitlab.com
I guess there is several thousand of those lines at gitlabs/githubs servers in .ssh/authorized_keys where every single line points out access to only that gitlab/hub account.
Please comment if you don't agree.
I have a react-native app that communicates with a server that makes calls to stripe for payment processing/customer creation. I want to ensure that requests are coming only from my app. so i figured i could create a token of sorts on the client, and encrypt it with a special key using b-crypt, then on the server side when the request comes in with the encrypted token as a parameter, i can decrypt that token with the same special key.
i understand the optimal place to store this key is in the env variables server-side, but how do you manage security of a secret key client-side in a react-native app?
There are several ways to store keys on the client side.
The easiest way is to use the Async storage which stores data in a key value pair.
The problem with Async storage is that its nor encrypted so it wont suit your requirement.
The other option is to use the react-native-keychain library which stores the passwords or keys in the securely in the keychain of IOS and keystore in Android. The security part will be managed by the operating system. So this is an approach that can be recommended for your requirement.
There are multiple ways to do this, these are just two options.
After further research, I ended up revoking the accepted status of #GuruparanGiritharan. his solution (react-native-keychain) dealt with storing passwords in an OS's keychain implementation. this ended up not being the solution for my question. as my question deals with storing secrets keys in a way they wouldn't be visible in binary, de-compiling situation.
What I did was research key management services. I found this:
Handling secrets with dotenv
In Node.js secrets are usually loaded from env files using the dotenv
module. This is done in order to separate the secrets from source
code. For example an env file might look like this (reference below):
DB_HOST=localhost
DB_USER=root
DB_PASS=s1mpl3
Now doing this in a context (potentially development) where you dont need to implement continuous integration, it's referred to a "manual provisioning"
My issue (admittedly, I did not specify a production environment in my question) is when it comes to a production environment, in my case, with visual studio app center (a CI option for React-Native apps)
Continuing on this site for an option for key management services:
While this removes hardcoded secrets from source code, it doesn’t
solve your problem completely; Now you need to find a way to provision
your app with the .env file.
This guide will show how you can remove the secrets from the .env file
altogether, so that it can be safely checked into source control and
shipped with your application.
This guide is discussing how to implement key management in the context of a production environment with continuous integration. This approach is relatively simple and straightforward, as all you need to do is create an .env file, add the keys with a variable, and add (in this tool's case) an additional run script to your main node.js start script.
Tool mentioned: SecretHub
https://secrethub.io/docs/guides/nodejs/
I use a deploy key with write access on Github with weblate. This way, I can finely tune whether weblate machine has access or not to a specific repository by adding/removing deploy keys.
It seems however that weblate uses only one private key and is not designed to use deploy keys. What is the recommended way of handling my problem?
On Hosted Weblate we're using separate user on GitHub. This allows you fine grained access control, while using just one ssh key. Also see https://developer.github.com/guides/managing-deploy-keys/#machine-users
But even with deploy keys, you can IMHO add same key to several GitHub projects.
I am doing some small devices running Debian. They need to sync a S3 bucket to a folder locally. I Have installed S3Tools and s3cmd sync seems to be the perfect tool. But I have to supply the Access Credentials and that seems VERY insecure. I will not be controlling the units once they ship so I need to somehow use the tool without supplying the credentials - AND I need to make sure the credentials can not delete in the bucket.
Does anyone have an idea as to how I go about this?
Regards, Jacob
Use IAM. It allows creation of AWS credentials with predefined permissions, which are under your control.
So you will create one identity per device. You are free to restrict access only to some buckets, keys.
You will not be able updating "device" credentials on your devices (this is simply your constrain), but in case some of your credentials will turn out as compromised, you still have the option to block it via IAM.
And for your primary "root" identity, I strongly recommend using two factor authentication (and of-course never put it to a device, you do not have control of).