Kubernetes 1.9 admission extension – What is it?

Kubernetes 1.9 includes powerful admission extension abilities that are part of the golden principles Kubernetes is being built on – you want to look for those principals in other solutions you are considering.

What is Admission?

Admission is the phase of handling an API server request that happens before a resource is persisted, but after authorization. Admission gets access to the same information as authorization (user, URL, etc) and the complete body of an API request (for most requests).

What are they good for?

Webhook admission plugins allow for mutation and validation of any resource on any API server, so the possible applications are vast. Some common use-cases include:

Mutation of resources like pods. Istio has talked about doing this to inject side-car containers into pods. You could also write a plugin which forcefully resolves image tags into image SHAs.

Name restrictions. On multi-tenant systems, reserving namespaces has emerged as a use-case.

Complex CustomResource validation. Because the entire object is visible, a clever admission plugin can perform complex validation on dependent fields (A requires B) and even external resources (compare to LimitRanges).

Security response. If you forced image tags into image SHAs, you could write an admission plugin that prevents certain SHAs from running.

More information here: http://blog.kubernetes.io/2018/01/extensible-admission-is-beta.html

Redhat Cloud Forms takes a bite into Cloud and Configuration Management

The latest Cloud Forms from Redhat targets the easy use of AWS Cloud Formation and OpenStack Heat templates import, customization, creation, deployment.

It offers a service catalog of Cloud resources setups including load balancers, servers and more.

It also makes it easier to customize your Cloud templates by offering forms and variables per the templates you pick.

Then it triggers Ansible Tower for in depth deployment and configuration management of your instances.

The Cloud Management portal shows you your Cloud components, instances, operating systems and applications including general Linux and Windows as well.

Sounds perfect?

Maybe it sounds like an enterprise vendor trying to grab it all..and maybe this time this vendor actually makes it..

I still would like to see TerraForm there as well..

Anyway there’s the video

Serverless and AWS Lambda Tips and Tools

  1. Use services that allow integration of feature flags through out your application to dynamically test, activate or suspend features that (some) your users should be using. Here is one such service: https://github.com/launchdarkly/featureflags/blob/master/README.md
  2. Track your external libraries through services that can alert of issues or vulnerabilities in those libraries – here is one such service called “Synk” – https://serverless.com/blog/4-ways-to-secure-prevent-vulnerabilities-in-serverless-applications/
  3. Store all your external libraries as a local copy in your internal repositories so that your are not affected by mistakes or vulnerabilities that affect the public code repositories ( such as NPM public repository for java – see details here on how it badly affected many applications https://www.theregister.co.uk/AMP/2016/03/23/npm_left_pad_chaos/ )
  4. Using a bigger memory tier could cause allocation of better CPU allocation which can bring your transaction processing speed from seconds to sub seconds
  5. Monitor performance metrics of your application to determine when it changed and why
  6. You must monitor for errors in your code. Don’t assume its working well
  7. Using Lambda inside VPC requires attention to security groups same as for an EC2 instance
  8. Make sure your Lambda function has the least privileges required in its IAM policy
  9. AWS Toolkit for Eclipse: Support for Creating Maven Projects for AWS, Lambda, and Serverless Applications http://bit.ly/2muxucL

Ansible Tower 3.1 brings Workflows Log integration and Clustering

Ansible Tower 3.1 brings the new “Workflows” feature allowing you to hook Playbooks, set conditions in executing them and passing data from one Playbook to another.

Additionally Tower can now scale beyond a single instance allowing job processing through any one of the tower nodes in the cluster.

In Tower 3.1 you can easily direct all logs to a central log service such as ELK, Splunk, loggly or others.

More information here: https://www.ansible.com/blog/introducing-asible-tower-3-1