How can I give server access to my Developer? - mongodb

I am have AWS EC2 Server with my App Backend and Database there.
My new developer needs to upload few things in the Database and update Backend code but I don't want to give him the PEM.
He needs to SSH
Whats the best possible way to do it? I was thinking of creating an IAM User for him - but I only want him to give SSH Access, so permission would that be? I could only find a general full permission EC2 which would also give him permission to edit the Security Group and things like that.
I do trust him well, but I just don't want to give him full access in general.
What can I do?

Why not allow your developer to connect using session manager.
If you use this he can access the environment either in his browser or via the AWS CLI.
He should be able to mimic a regular session but without having the key, then when he's done you remove the permissions of the server. You can also enable logging to check the history of his sessions actions.
If you want to update code you should at some point take a look at using code deploy to have the code automatically rolled out without even accessing the server.

Related

Is there a way to use a non-login user to run Rundeck jobs?

So my goal is to create a Rundeck job that runs on a schedule and isn't run as my personal user, or any "regular" user, but rather a bot user. Ideally this bot user wouldn't have login access and restricted permissions for security reasons, but would be able to run certain jobs. I've tried searching, but the only information I'm finding is about how to create a "regular" user in Rundeck. Even if I go down that route of creating the bot user as a "regular" user, to use it, you need to pass in either the login credentials or an API token. An API token would be fine, if it could be generated and pulled in on the fly. However, that is not the case, the API has an expiration itself. If there is something I'm missing, please let me know. I'd love to get this working.
Rundeck Version: Rundeck 3.2.1-20200113
Rundeck Cli Version: 1.1.7
You can set the following configuration in your rundeck-config.properties file (usually at /etc/rundeck/ directory):
rundeck.api.tokens.duration.max=0
This will disable your maximum period, you can see this in the official documentation here.
With that, your "bot user" can do it through API / RD CLI as you wrote.
Try using webhooks https://docs.rundeck.com/docs/manual/12-webhooks.html
You can trigger a job by making a http-request
The way I've implemented bots is as a user who is a member of a 'bot' user group, with ACLs that lock down that group as required. Any passwords required for the scheduled job are loaded into the key storage of the bot user.
With this approach you still need someone who knows the bot credentials to login as them and set passwords/SSH keys, but that's a one-off. Is that what you're trying to avoid?
The one annoying thing I've found is that a scheduled job always seems to run as the last user to edit the job - so I grant edit access to bot users and make sure to set/reset the schedule after any edit by a normal user. Hoping to address this through https://github.com/rundeck/rundeck/issues/1603, you might want to give it a 👍.

Using AWS KMS and/or credstash with non AWS server

Is it possible to use AWS KMS and a tool like credstash without the use of EC2 or equivalent or does it rely solely on IAM roles?
I've got a server elsewhere where I am testing some things out and ultimately I will be looking at migrating an app to EC2 etc. to make use of scaling. But for now whilst I'm setting up my deployment pipeline etc. I wondered if it was still possible to make use of KMS on my non-aws provisioned server?
The only possible way I can think of is by installing the AWS CLI tools on the server in question. Does this sounds like the right approach?
What #Viccari said is correct (in the comments). In terms of what you want to do (store passwords), the AWS Parameter Store would be a good fit for you. See https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html for more information. The guide explicitly calls out your use-case:
Parameter Store offers the following benefits and features.
Use a secure, scalable, hosted secrets management service (No servers to manage).
In the end, if you end up using Parameter Store or KMS, you will need some sort of credentials stored somewhere to grab an AWS STS token to use to call the underlying AWS services. If working outside of AWS EC2, you will need the AWS Access Key and AWS Secret Key from an IAM user. If you are in EC2, the IAM instance role will magically provide you the credentials and use that role to call those AWS services. The AWS SDK does this for you behind the scenes.
But, as you state, you don't want to run this in EC2 (to save money, or other reasons). The quickest way to store these credentials is to have them in a un-tracked file (added to your .gitignore) you can source from as environment variables, which your program will then read. This allows you to do local testing, and easily run it in EC2
with zero code changes. See https://docs.aws.amazon.com/cli/latest/userguide/cli-environment.html for what variables to set. Note that this doc talks about the CLI; the SDK's follow the same behavior.

Get IBM Bluemix SQL Database service credentials before I bind it to application, is it possible?

When I bind SQL Database service to an application I can see credentials from application panel. But in case I've created a service and would like to work with it before I'm binding to any application, is it possible? I haven't find a way to see credentials, only internal tools to work with database.
Thank you.
Once you provision a new SQL Database instance, you need to enter the service details page in bluemix, find the 'Launch' button to go to the service page which will open up separately. On the service page go to Set up `-->` Connect Applications `-- >` Connection settings. You will get all the connection details except the username and password.
If you are not able to resolve the username and password then you have got two alternatives :-
1. Create a dummy application, bind it to your SQL Database, get the credentials from VCAP_SERVICES, and you can use them externally.
2. If you are looking for something only on `DB2` then you have another alternative called `DashDB` available in Bluemix. Here the settings are well defined, credentials are clearly available and will work even without binding the service to an application.
Hope this helps you. Thanks.

How to deploy with password (MeteorJS)

Is it still possible to deploy to meteor.com and protect it using a password?
When I search for this I find things like
$> mrt deploy -P example.meteor.com
but that doesn't work. I guess something has changed here and I get the impression this feature is removed
Meteor no longer supports deploying with a password directly, and for good reason!.
All publishes are linked to a Meteor developer account. These give:
Ability to allow other users to have access to your apps
Abililty to see all sites you have
Ability to publish without putting in your password every time
(In future) more fine grained permissions options (I'd imagine, considering galaxy's commercial target base).
Simply meteor login, or publish your app like you would normally to kick off the signup process. You can meteor logout to switch to another account.
After you deploy your app, you can see the sites you are authorized with meteor list-sites.

FileMaker XML Web Publishing

We currently have a FileMaker Server instanace running, it already has PHP web publishing running.
I'm just wondering is it as simple as ticking enable XML web publishing for it to be up and running or have I got to restart the server??
Thanks
You need to enable it in the server deployment, then you need at least 1 user account in the file with the extended privilege to grant access via php/xml/iwp etc. You will need a user account in EACH file you want to have access to with the appropriate extended privilege.
Then comes the fun of actually working with the FMXML or FMPHP engine hehe.