Forge configuration What to Put in Server Providers=>Amazon=>Key/Secret - laravel

I created an Ubuntu server on Amazon AWS.
Then I registered for Forge, and now trying to configure it.
I selected source control to be Bitbucket.
I selected Amazon in Server Provider Section,but now I am not sure what to put in key and secret

I found the answer to this question,
We need to create a IAM user and opt for api access key and secret.
also remember to give access to at least FullEC2Admin Access to this user before initiating the process to create and provision the server via forge.

Related

Is it possible to prevent the leakage of the original data of the database even if it is hacked?

We want to build a web application and deploy it on AWS.
EC2: Laravel
RDS: MySQL
I will use Laravel's encrypter to encrypt the data of database. Even RDS got hacked, the data have encrypted. Hacker can't know the contents. But if EC2 got hacked, hacker can get the database credential and the encryption key on the source code and decrypt the encrypted data from database.
My Boss (maybe client) think that it is not enough because of the database contains sensitive informations of users. He want to prevent the leakage of the original data of the database even if the web server (EC2) got hacked. Is it possible?
If not, I think we should focus on make the web server more difficult to be hacked:
Set Security Group to limit ssh access by IP address.
Or any other measures?
Here are a few safety measures you can do to reduce your blast radius.
Move your credentials for the RDS database so they are not directly on the instance, use a credential store such as:
AWS Secrets Manager
HashiCorp Vault
Rotate your database credentials frequently, and use IAM roles for your EC2 applications and not IAM users.
Keep your EC2 and RDS within private subnets, add an ELB in front of the EC2 so that public traffic can only access this device only.
Configure security groups to scoped to only what they need, limit inbound access to your AWS VPC to a VPN or direct connect connection.
Restrict access to who can do what in your AWS account, if a user does not need to perform certain actions for their role then just remove those permissions. This will prevent an accidental action on a service the user should not be using.
AWS have a large number of actions you can do in the security pillar too, so make sure to take a read of that.

VB6: How to connect to a network shared folder, without providing credentials using

I want to connect to a network share path '\domainname\folder-name' using domain account, without passing credentials, through my VB6 code.
My legacy VB6 application service (running on server A) currently accesses shared folder (on server B) using local account credentials(stored in encrypted .ini file). This service is running on behalf of 'LocalSystem'.
application is using 'WNetUseConnection' API to connect to shared folder.
To ensure security local account needs to be replaced by 'domain account' and password policy should be CyberArk dynamic password.
Now this credentials can't be stored in .ini file anymore. The idea that I am working on is to get service running on behalf of 'domain account' rather 'LocalSystem'. My thought is if i make service run on behalf of 'domain account, and give relevant permissions to this account on shared folder. Shared path should be accessible to service without providing credentials.
I need help to understand which API shall I use.
The API(s) you'll need for this is WNetAddConnection.
See this example.

How to start using Minio without accessKey and secretKey?

I have a minio server running on debian using SystemD and proxied with NGINX and secured with Let's Encrypt. In the docs it suggests the service is comparable to Amazon S3 but I can't figure out how to actually use the service.
Version: 2019-03-27T22:35:21Z
Release-Tag: RELEASE.2019-03-27T22-35-21Z
Commit-ID: 6df05e489dc789cf26e82810cf5cfeefb1d90761
It looks like in order to create a bucket or use the minio cli mc there needs to be a registered TARGET along with accessKey and secretKey. I can't find anywhere on the server where that information is available and it's not clear to me how to create a new target.
Here is the /etc/default/minio file:
MINIO_VOLUMES="/usr/local/share/minio"
MINIO_OPTS="-C /etc/minio --address :9000"
There are no files in /etc/minio.
It's running and set up, but how can I start actually using the minio server?
Edit: Config JSON
I tried creating a new config file and entering new accessKey and secretKey in the credential field. I was not able to sign in to the Minio Browser app using the same keys.
Edit: Key Files
I tried entering a new access key and secret key into the files /etc/minio/access_key and /etc/minio/secret_key and adding the following lines to the /etc/default/minio environment file:
MINIO_ACCESS_KEY_FILE="/etc/minio/access_key"
MINIO_SECRET_KEY_FILE="/etc/minio/secret_key"
I restarted the service systemctl restart minio but I still can't log into the Minio Browser app.
It only worked to provide MINIO_ACCESS_KEY and MINIO_SECRET_KEY into /etc/default/minio environment file. Every other method failed.
I used the following to generate a secret key that resemble AWS access keys in the example. In the CLI help text it looks like access key and secret key would work however.
SecureRandom.urlsafe_base64(30)

Accessing cassandra without hardcoded username password

I have an existing Datastax Cassandra setup that is working. We just added authentication to the system and now we can log in with our AD accounts. This is very nice and certainly works. However applications need to use a hard-coded username/password in order to connect.
In SQL Server we were able to setup a user to run the service as and then it would connect and work through AD. However in Cassandra it is not the same.
If I don't want to include usernames and especially passwords in my app.config files what are my options?
You can use authentication via LDAP with DSE (Datastax Enterprise), so the authentication stage is done with LDAP instead of the internal authentication in DSE which you're using at the moment. Note that my comments here apply to DSE5.0 onwards but you can use LDAP auth with earlier versions of DSE from 4.6 onwards.
The documentation (link below) covers this. The basic steps are as follows:
Configure your authenticator in the cassandra.yaml to use the DSE authenticator
authenticator: com.datastax.bdp.cassandra.auth.DseAuthenticator
Create an internal role in cassandra to map to the LDAP group(s) in your LDAP server using the CREATE ROLE command
Ensure all the users you need to use map to the relevant LDAP group (part of your LDAP config)
Configure your dse.yaml to have the correct settings for your LDAP server
Restart the DSE process for the settings to take effect
The following documentation gives some good examples and background information:
https://docs.datastax.com/en/latest-dse/datastax_enterprise/unifiedAuth/unifiedAuthConfig.html
https://docs.datastax.com/en/latest-dse/datastax_enterprise/sec/authLdapConfig.html
Note: when configuring the dse.yaml note the comment in the docs regarding user_search_filter:
When using Active Directory set the filter to (sAMAccountName={0})

How to grant EC2 access to SQS

The docs are very confusing to me. I have read through the SQS access docs. But what really throws me is this page: http://docs.aws.amazon.com/aws-sdk-php/v2/guide/service-sqs.html
You can provide your credential profile like in the preceding example,
specify your access keys directly (via key and secret), or you can
choose to omit any credential information if you are using AWS
Identity and Access Management (IAM) roles for EC2 instances or
credentials sourced from the AWS_ACCESS_KEY_ID and
AWS_SECRET_ACCESS_KEY environment variables.
1) Regarding what I have bolded, how is that possible? I cannot find steps whereas you are able to grant EC2 instances access to SQS using IAM roles. This is very confusing.
2) Where would the aforementioned environment variables be placed? And where would you get the key and secret from?
Can someone help clarify?
There are several ways that applications can discover AWS credentials. Any software using the AWS SDK automatically looks in these locations. This includes the AWS Command-Line Interface (CLI), which is a python app that uses the AWS SDK.
Your bold words refer to #3, below:
1. Environment Variables
The SDK will look for the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables. This is a great way to provide credentials because there is no danger of accidentally including a credentials file in github or other repositories. In Windows, use the System control panel to set the variables. In Mac/Linux, just EXPORT the variables from the shell.
The credentials are provided when IAM users are created. It would be your responsibility to put those credentials into the environment variables.
2. Local Credentials File
The SDK will look in local configuration files, such as:
~/.aws/credentials
C:\users\awsuser\.aws\credentials
These files are great for storing user-specific credentials and can actually store multiple profiles, each with their own credentials. This is useful for switching between different environments such as Dev and Test.
The credentials are provided when IAM users are created. It would be your responsibility to put those credentials into the configuration file.
3. IAM Roles on an Amazon EC2 instance
An IAM role can be associated with an Amazon EC2 instance at launch time. Temporary credentials will then automatically be provided via the instance metadata service via the URL:
http://instance-data/latest/meta-data/iam/security-credentials/<role-name>/
This will return meta-data that contains AWS credentials, for example:
{
"Code" : "Success",
"LastUpdated" : "2015-08-27T05:09:23Z",
"Type" : "AWS-HMAC",
"AccessKeyId" : "ASIAI5OXLTT3D5NCV5MS",
"SecretAccessKey" : "sGoHyFaVLIsjm4WszUXJfyS1TVN6bAIWIrcFrRlt",
"Token" : "AQoDYXdzED4a4AP79/SbIPdV5N8k....lZwERog07b6rgU=",
"Expiration" : "2015-08-27T11:11:50Z"
}
These credentials have inherit the permissions of the IAM role that was assigned when the instance was launched. They automatically rotate every 6 hours (note the Expiration in this example, approximately 6 hours after the LastUpdated time.
Applications that use the AWS SDK will automatically look at this URL to retrieve security credentials. Of course, they will only be available when running on an Amazon EC2 instance.
Credentials Provider Chain
Each particular AWS SDK (eg Java, .Net, PHP) may look for credentials in different locations. For further details, refer to the appropriate documentation, eg:
Providing AWS Credentials in the AWS SDK for Java
Providing AWS Credentials in the AWS SDK for .Net
Providing AWS Credentials in the AWS SDK for PHP

Resources