It has been a busy week with the day job of delivering to customers, with a webinar with Oracle, Flexagon and a customer – Heathrow Airport. Plus two technical sessions for DOAG.
Webinar
The webinar is the latest step in the partnership between Capgemini and Flexagon. If you’d like to see it, the recording can be accessed here.
The webinar development was very much a team effort with Oracle providing the hosting and promo logistics (particularly from Jurgen Kress and input from Daryl Eicher). Presentation development effort with Flexagon (Dan Goerdt and Tanya O’Connor). Of course the great input from our Heathrow customers – Mark South and Nick Byng-Maddick.
We have another blog post related to the webinar sharing some more detail. This will be published in a week or so on blog.oracle.com.
DOAG
The Deutsche Oracle Anwendergruppe (DOAG) conference took place virtually this week. DOAG and the UKOUG events are probably the biggest of the European user group events. With UKOUG happening at the end of the month.
My presentations at DOAG have been an update on which GraphQL, gRPC or REST API technology to use (see the presentation material here), along with a brand new presentation, again relating to APIs. But this time we’re looking at the application and capabilities of the Oracle Cloud’s API which can allow us to manage a wide range of services (see here). While I don’t have the demo piece recorded, you can see the slide aspect here.
Coming up
As mentioned I will be presenting at UKOUG Together. I have another brand new presentation for this as well, which will look at GitHub Actions combined with Oracle Cloud. We also have our first 2022 conference confirmed, in the form of API World.
I recently presented at APIWorld about how API definitions go beyond the payload specification into providing details of terms and conditions and so on. You can see the presentation here (more about my presentations here).
One of the questions during the presentation did I have other examples of good APIs, reflecting the points I’d made. A very valid question, to which I didn’t have more examples to hand, hence this post.
So the easy answer would be to point to an excellent article on Nordic APIs (here) that address the question and explain why they rate the APIs. But that’s a little bit of a lazy answer and in all fairness, the examples provided are from organisations where APIs are recognised as a primary or important contributor to business revenue. So I’ve looked at areas where the API may not necessarily be seen by the business as the primary source of revenue. With the examples provided, we’ve described what we think is good, or not so good about them. Hopefully, through these examples, you’ll see why points are made in the presentation. So here are my reviews…
The latest edition of OraWorld is out which includes the second part of my part part articles relating to GraphQL and API Security. You can check it out at on page 22, along with lots of other great content here.
Last night saw the final chapter of Logging in Action with Fluentd go back to my editor. The next step is that Chapter (and others I hope) will go to MEAP, so early readers not only get the final chapter, but also the raft of improvements we’ve made. Along with that, the manuscript goes for a full peers review. Once that’s back, its time for a round of edits as I address the feedback then into copy editing and Manning sign off review.
As you might have guessed, we’ve kept busy with an article in the 25th edition of OraWorld. This follows Part 1 talking about GraphQL with a look at considerations for API Security.
In addition to that we’re working on a piece around automation of OCI management activities such as setting up developers, allowing them a level of freedom to experiment without accidentally burning through all your credits by spinning up Exadata servers or 500 node Kubernetes clusters.
We might even have some time to write more about APIs and integration.
So this week the big Developer Week Europe conference is running online at the moment. I got to present today. It was a relatively short session, with an unfortunate brief interruption of a smoke alarm. My presentations is here …
The latest edition of OraWorld has become available to today. With its blend of insight into the Oracle community, and Oracle technologies from database to modern apps. I have to own up and say, I mention the magazine not only because of the beautifully crafted independent insights, but also it includes an article from myself. Taking a look at GraphQL what it is and how recent new Oracle product features could make a big difference to the GraphQL adoption opportunities.
The next edition should include a follow up article to this focussing on API security considerations.
A couple of years ago I got to discuss some of the design ideas behind API Platform Cloud Service. One of the points we discussed was how API Platform CS kept the configuration of APIs entirely within the platform, which meant some version management tasks couldn’t be applied like any other code. Whilst we’ve solved that problem (and you can see the various tools for this here API Platform CS tools). The argument made that your API policies are pretty important, if they get into the public domain then people can better understand to go about attacking your APIs and possibly infer more.
Move on a couple of years, Oracle’s 2nd generation cloud is established an maturing rapidly (OCI) and the organisational changes within Oracle mean PaaS was aligned to SaaS (Oracle Integration Cloud, Visual Builder CS as examples) or more cloud native IaaS. The gateway which had a strong foot in both camps eventually became aligned to IaaS (note that this doesn’t mean that the latest evolution of the API platform (Oracle Infrastructure API) will lose its cloud agnostic capabilities, as this is one of unique values of the solution, but over time the underpinnings can be expected to evolve).
Any service that has elements of infrastructure associated with it has been mandated to use Terraform as the foundation for definition and configuration. The Terraform mandate is good, we have some consistency across products with something that is becoming a defacto standard. However, by adopting the Terraform approach does mean all of our API configurations are held outside the product, raising the security risk of policy configuration is not hidden away, but conversely configuration management is a lot easier.
This has had me wondering for a long time, with the use of Terraform how do we mitigate the risks that API CS’s approach was trying to secure? But ultimately the fundamental question of security vs standardisation.
Mitigation’s
Any security expert will tell you the best security is layered, so if one layer is found to be vulnerable, then as long as the next layer is different then you’re not immediately compromised.
What this tells us is, we should look for ways to mitigate or create additional layers of security to protect the security of the API configuration. These principles probably need to extend to all Terraform files, after all it not only identifies security of not just OCI API, but also WAF, networks that are public and how they connect to private subnets (this isn’t an issue unique to Oracle, its equally true for AWS and Azure). Some mitigation actions worth considering:
Consider using a repository that can’t be accidentally exposed to the net – configuration errors is the OWASP Top 10. So let’s avoid the mistake if possible. If this isn’t an option, then consider how to mitigate, for example …
Strong restrictions on who can set or change visibility/access to the repo
Configure a simple regular check that looks to see if your repos have been accidentally made publicly visible. The more frequent the the check the smaller the potential exposure window
Make sure the Terraform configurations doesn’t contain any hard coded credentials, there are tools that can help spot this kind of error, so use them. Tools exist to allow for the scanning of such errors.
Think about access control to the repository. It is well known that a lot of security breaches start within an organisation.
Terraform supports the ability to segment up and inject configuration elements, using this will allow you to reuse configuration pieces, but could also be used to minimize the impact of a breach.
Of course he odds are you’re going to integrate the Terraform into a CI/CD pipeline at some stage, so make sure credentials into the Terraform repo are also secure, otherwise you’ve undone your previous security steps.
Minimize breach windows through credentials tokens and certificate hanging. If you use Let’s Encrypt (automated certificate issuing solution supported by the Linux Foundation). Then 90 day certificates isn’t new.
Paranoid?
This may sound a touch paranoid, but as the joke goes….
Just because I’m paranoid, it doesn’t mean they’re not out to get me
Fundamental Security vs Standardisation?
As it goes the standardisation is actually a dimension of security. (This article illustrates the point and you can find many more). The premise is, what can be ensured as the most secure environment, one that is consistent using standards (defacto or formal) or one that is non standard and hard to understand?
I presented at an online Meetup on today (Thursday 16th April) with a shortened version of my API technology overview (A quick look at gRPC, GraphQL, REST APIs – Which way to go?). Aside from an early interruption to the event, the evening was an excellent series of speakers covering a number of API centric subjects.
We’ve added a new mindmap to our catalogue here. This covers the core of GraphQL. The catalogue contains both the image and a Word representation. The map is built based on a reading of Learning GraphQL by Eve Porcello & Alex Banks on O’Reilly.
Phil (aka MP3Monster)'s Blog 
You must be logged in to post a comment.