Schlomo Schapiro

While Google Docs is a great productivity tool, it still lacks some very simple and common functionality, for example setting a custom page size. Google Slides and Google Drawings allows setting custom sizes, but not Google Docs . Luckily there are several add-ons available for this purpose, for example Page Sizer is a little open source add-on on the Chrome Web Store . Unfortunately in many enterprise setups of G Suite access to the Chrome Web Store and to Google Drive add-ons is disabled for security reasons: the admins cannot white-list single add-ons and are afraid of add-ons that leak company data. Admins can only white list add-ons from the G Suite Marketplace . The Google Apps Script code to change the page size is actually really simple, for example to set the page size to A1 you need only this single line of code: DocumentApp. getActiveDocument(). getBody(). setAttributes({ "PAGE_WIDTH": 1684, "PAGE_HEIGHT": 2384 }); To solv...

Following up on " Lifting the Curse of Static Credentials ", everybody should look closely at how they handle shared accounts, robot users or technical logins. Do you really rotate passwords, tokens and keys each time somebody who had access to the account leaves your team or the company? Do you know who has access? How do you know that they didn't pass on those credentials or put them in an unsafe place? Update : In May 2024 I gave a talk about this ( Video ,  Slides ): For all intents and purposes, a shared account is like anonymous access for your employees. If something bad happens, the perpetrator can point to the group and deny everything. As an employer you will find it nearly impossible to prove who actually used the password that was known to so many. Or even to prove that it was one of your own employees and not an outside attacker who "somehow" stole the credentials. Thanks to identity federation and federated login protocols like SAML2 and...

Update 23.04.2018: Added demo and link to conference talk video/slides at the end of this article Kubernetes is a great way to run applications because it allows us to manage single Linux processes with a real cluster manager. A computer with multiple services is typically implemented as a pod with multiple containers  sharing communication and storage : Ideally every container runs only a single process. On Linux, most applications have three phases with two different programs or scripts: The initialization  phase, typically an init script or a systemd unit file. The run  phase, typically a binary or a script that runs a daemon. The maintenance  phase, typically a script run as a CRON job. While it is possible to put the initialization phase into a Docker container as part of the ENTRYPOINT script, that approach gives much less control over the entire process and makes it impossible to use different security contexts for each phase, e.g. to prevent ...

Last week I wrote about understanding IAM Roles , let's follow up with some practical aspects. The following examples and scripts all use the  aws-cli  which you should have already installed. The scripts work on Mac and Linux and probably on Windows under  Cygwin . To illustrate the examples I use the case of an S3 backup bucket in another AWS account. For that scenario it is recommended to use a dedicated access role in the target AWS account to avoid troubles with S3 object ownership. AWS Who Am I? The most important question is sometimes to ascertain the identity. Luckily the aws-cli provides an option for that: $ aws sts get-caller-identity {     "Account": "123456789",     "UserId": "ABCDEFG22L2KWYE5WQ:sschapiro",     "Arn": "arn:aws:sts::123456789:assumed-role/PowerUser/sschapiro" } From this we can learn our AWS account and the IAM Role that we currently use, if any. AWS Assume Role Script The following Bash s...

One of the most important security features of Amazon AWS are IAM Roles. They provide a security umbrella that can be adjusted to an application's needs in great detail. As I all the time forget the details I summarize here everything that helps me and some useful tricks for working with IAM Roles. This is part one of two . Understanding IAM Roles From a conceptual perspective an IAM Role is a sentence like Alice may eat apples : It grants or denies permissions (in the form of a access policy ) on specific resources to principals. Alice is the principal, may  is the granting, eat  is the permission (to eat , but not to look at ) and apples  is the resource, in this case any kind of apples. IAM Roles can be much more complex, for example this rather complex sentence is still a very easy to read IAM Role: Alice and Bob from Hamburg may find, look at, smell, eat and dispose of apples № 5 and bananas . Here we grant permissions to our Alice and to some Bo...

Who has root access in your IT organizations? Do you "do" DevOps? Even though getting root access was once my personal motivation for pushing DevOps, I never considered the question of the relationship till it was triggered by my last conference visit. Last week I attended the 10. Secure Linux Administration Conference - a small but cherished German event catering to Linux admins - and there where two DevOps talks: DevOps in der Praxis (Practical DevOps) by Matthias Klein and my own DevOps for Everybody talk. I found it very interesting that we both talked about DevOps from a "been there, done it" perspective, although with a very different message. DevOps ≠ DevOps For me DevOps is most of all a story of Dev and Ops being equal, sitting in the same boat and working together on shared automation to tackle all problems. My favourite image replaces humans as gateway to the servers with tooling that all humans use to collaboratively deliver changes to the ser...