If you read some of my earlier blog posts, you know that I automated the setup (onboarding) for workshops and hackathons. Thus far, running my Terraform scripts to deploy resources and privileges meant allowing access to them. Thanks to a (relatively) new IBM Cloud security feature called time-based restrictions, I can decouple the deployment process from when access is possible.

In this blog post, I am going to give a short introduction to time-based restrictions. Then, I’ll walk you through my use case and how I implemented it:

Overview: Time-based restrictions

Identity and Access Management (IAM) allows you to protect your IBM Cloud resources. You’ve probably learned to utilize access groups, trusted profiles, service and user identities and how to assign access. By adding time-based restrictions, you can scope these access policies further to a specific time and date range (once) or to recurring windows. The latter could be maintenance windows—for example, over the weekend or specific hours during the night. Typical examples for single events (once) are ad-hoc maintenance work for some hours or some scheduled longer tasks with a given start and end.

When creating a new policy, you can now optionally add conditions for when the access should be granted. In the IBM Cloud console’s browser UI, that optional step is offered (see the image below). I could have also utilized the CLI or API/SDK, but for my automated setup of workshop resources, I picked Terraform:

Scenario: Workshops

As discussed in my blog “Secure Onboarding for Your Workshops and Hackathons,” I sometimes need to run short-lived projects. For these projects, it is crucial to automate the onboarding and offboarding to always set up the workshop environment the same way. Participants should have access privileges related to their role. So far, I would deploy the resources using Terraform (including all privileges) and destroy resources and access after the event.

By adding time-based restrictions to the access policies, I am able to grant access in stages. Once again, I deploy everything with Terraform, including IAM privileges. However, the time-related conditions make sure that the policies are only active between the start and end times. They could be set to align with the workshop start and the official end (or some hours/days later). Without destroying the resources, access to them is automatically cut off after the workshop.

The following shows the sample conditions that I added to the shared Terraform code. You can find it all in the GitHub repository cloud-project-onboarding-terraform and the branch workshop_hackathon. The screenshot at the top of this blog post shows the same conditions in the IBM Cloud console.

 rule_conditions {
    key = "{{environment.attributes.current_date_time}}"
    operator = "dateTimeGreaterThanOrEquals"
    value = ["2023-07-19T09:00:00+01:00"]
  }
  rule_conditions {
    key = "{{environment.attributes.current_date_time}}"
    operator = "dateTimeLessThanOrEquals"
    value = ["2023-07-26T09:00:00+01:00"]
  }
  rule_operator = "and"
  pattern = "time-based-conditions:once"

Conclusion

Time-based restrictions are a great addition to the existing IBM Cloud security features. They allow you to reduce assigned access to a single time, date ranges or recurring maintenance windows, thereby reducing the attack surface. For my use case of automated onboarding and offboarding, the time-based restrictions allow me to decouple resource and privilege deployment from activating access. This means I have more flexibility in when to perform administrative tasks.

Want to learn more? Here are my suggestions:

• Read the overview blog post “Secure Onboarding for Your Workshops and Hackathons” for background and further links for the onboarding/offboarding scenario.
• Study the IBM Cloud documentation on that security feature: Limiting access with time-based conditions
• Check out the sample code for the scenario on GitHub: https://github.com/data-henrik/cloud-project-onboarding-terraform

If you have feedback, suggestions, or questions about this post, please reach out to me on Twitter (@data_henrik), Mastodon (@data_henrik@mastodon.social) or LinkedIn.