Pages

Subscribe:

Sunday, December 16, 2018

[Solved] ERROR: The data in your request was invalid Response: Field 'metadata.name' invalid

This error occurs when you try to upload the chef cookbook on the chef server using the knife command.

The reason for the error is its missing the metadata.name which is used to identify the name of the cookbook and helps to figure out the compatibility with the chef version that you are running.

To overcome this issue you need to create a metadata.rb file in your recipe and put the following content inside the metadata.rb file

 name ''  
 maintainer 'Ankit' 
 maintainer_email '[email protected]
 license 'All Rights Reserved'  
 description 'Installs/Configures  
 long_description 'Installs/Configures 
 version '0.1.0'  
 chef_version '>= 12.14' if respond_to?(:chef_version)

Thursday, December 13, 2018

(Solved) Free storage dropped to 0 on aurora/rds node

When the slow_log is enabled and the long_query_time is set to 0 , this will cause the instance to log all the queries on the DB.

This can cause the downtime in the Database always ensure you are not enabling these settings to log everything , it should only be enabled for a short period of time for debugging purpose only.

Wednesday, December 12, 2018

TLS 1.3 support with nginx plus

TLS 1.3 support is now available, bringing the latest performance and security improvements to transport layer security. This includes 0-RTT support, for faster TLS session resumption. TLS 1.3 can be used to provide secure transport for both HTTPS and TCP applications. OpenSSL 1.1.1 or newer is required to provide TLS 1.3. At the time of release OpenSSL 1.1.1 is available with Ubuntu 18.10 and FreeBSD 12 (shortly after release).

Tuesday, December 11, 2018

Storing AWS passwords secretly on mac

If you are managing large number of the AWS Accounts in your organisation than its better to use some federated solution.

However if you are using passwords only than you can use the KeepPassXC
https://keepassxc.org/download/#mac

To securely store all your passwords in the keepassxc.

It maintains its own database and you can take the backup of the database to keep your password safe. It does not sync them externally thus lowering the threat of compromise.

In case your laptop corrupts you can import the database which was created earlier and you would be able to see the credentials.

Everytime you open your database you will have to unlock it initially before gaining access to the secrets.

Its much of the use is similar to the Hashicorp vault just the difference is instead of application making the request you keep your password in the keepassXC.

Important points regarding the use of the spot instances in the AWS

1. If you are using the balanced orientation which is a mix of cost orientation along with the availability orientation, it means it will always launch instances that have lowest pricing at the moment in the Az's along with the longest duration without any disruptions. Spot instances service provider usually make choices based on the lowest pricing and long lasting instances. But this does not mean these service provider will evenly spread between AZ's i.e. balanced orientation is not always balanced distribution.

2. You can usually change this by selecting the availability orientation but this options narrows down the possibility of long continuity instance types in case volatility increases so choose that option with consideration.

3. Now there can be issue in case your subnet is not having sufficient capacity to create more ip address. This can happen when there are not enough free addresses available in the subnet to satisfy the requested number of instance.

4. Also if the instances has already reached the maximum number of instances in elasticgroup configuration than also new instances won't be spawn so in this case you should monitor the value i.e. current instances is always 25% lower than maximum instances in case you receive some spike and more containers are required to be deployed due to which more servers are required to spin up.

Wednesday, December 5, 2018

Aliyun Cloud Important Points

There are two versions available for aliyun cli
  • CLI Go Version
  • CLI Python Version
Make sure Go Version is to be installed as python version is going to be deprecated.

You can refer to the below link for the Aliyun Cli installation
https://github.com/aliyun/aliyun-cli?spm=a2c63.p38356.a3.1.17414388la2EgQ

Creating a VPN Tunnel

  • Create VPN Gateway.
  • Create Customer Gateway and enter Office Gateway IP as Customer gateway IP address.
  • Create IPSec Connection. Consider following important points -
    Local Network - VPC CIDR
    Remote Network - Office Network CIDR
    Encryption Algorithm - aes192
  • Download vpn configuration and share with network team. In mail, mention ports to be opened usually 22, 80, 443.
  • Once the network team has configured the configuration on there end of  tunnel. Tunnel will be up in IPSec connection section.
  • Update route table. Allow required port from the other end of the Tunnel NAT IP to allow the traffic to flow securely over the private tunnel.

Sunday, December 2, 2018

Most Important Security Practices

  • Remove all passwords, keys etc from code and use vaults/jks etc for storing them securely
  • Review all exposed APIs in terms of sanitising input params, build rate controls, authentication, and source whitelisting
  • Build DDoS protection by reviewing perimeter architecture, implementing a WAF, put request rate limits at load balancer
  • Keep reviewing all security groups, firewall rules, patch any system with vulnerable components
  • Start secure code reviews for all releases and review input sanitisation, query parameterisation and other OWASP items.

Best Practices with Mysql Databases

  • Stored Procedures should not be used.
  • All Queries taking more than 500 ms are classified as Bad Queries and will be considered as Blocker Bugs
  • No unnecessary complex joins and no shared databases across multiple applications/services.
  • Every database should have it's own Access Control
  • Connections and Throttle Limits should be setup.
  • Schema Migrations should not have any down time.
  • Every database should have a Candidate Master and Multi-Redundancy
  • Every database should have Orchestration setup with auto failure mode setup.
  • All databases should be part of Monitoring

Database Proxy

Database proxy is a middleware which once setup in place will ensure that all reads/writes from the application passes through it. It can serve following purposes.
1) Balancing the load due to queries being performed on database. In most setups, database slaves are used with a DNS. This doesn't help in balancing the queries which are being performed on the slaves. It has been observed that while one slave is heavily loaded, the other is almost idle which clearly indicates balancing is not done in the right way and overall performance of the read queries are also degrading than the resources being used.
2) Routing/Rejecting queries based on regex. This allows the Engineering team to have the capability of blacklist filters on certain clauses depending upon the current indexes in the table. This will ensure, queries executed from mysql cli client do not impact critical slaves. There is more that can be achieved with this feature.
3) Automatically shun slaves with replication lag ProxySQL automatically stops routing the queries to a slave that are facing lag. No more replication lag related bugs.

ProxySQL

To achieve above requirements/goals, the ProxySQL should be used. ProxySQL is a high performance MySQL proxy that can scale up to hundreds of backend servers.

Topology


Integration

Application that want to leverage the proxy can use the Proxy ELB DNS in their applications rather than using the DNS. Database teams can setup the required Slave server host group.


Engineering Best practices to be followed

1. All teams should use confluence:-
i.e. all team documents, on call process, how to, team details etc should be publish to the confluence itself. Documents should not be shared in the email of texts.

2. Publish Design documents for future release:-
Design documents should have following structure
Status, authors, reviewers, overview, goals both business level and tech level goals, Design, Architecture, Tech stack, changes in existing systems, APIS, public apis, non public apis, security, system infra details, testing , monitoring and alerting, disaster recover, failover, production readiness checklist, faqs.

3. Code quality:-
a. Supported ides and minimum version.
b. Use of bitbucket/gitlab and code style guildlines

4. Code Documentations and Guidelines:-
a. Code commit should have JIRA ID with each and every commit
b. Release branches should be properly defined.

5. Code Review:-
a. publish code review checklist
b. Tools to track code review
c. Cross teams review for critical features.