Permission Management for Databases

Table of Contents

Part 1: Permission management for databases

Permission management for databases is a sore spot in many DevOps pipelines. 

It requires a careful balancing act between access control and productivity. On one hand, privileged access exposes the organization to risks. On the other hand, if we restrict it too much, we end up with bottlenecks resulting in a lack of productivity. It’s a lose-lose situation. 

It’s Important to Limit Direct Access

Companies strive to limit direct access concerning permission management for databases for many reasons, such as security, as a fail-safe against potential human errors and a number of other benefits. No matter the reason, this type of least-privilege access policy has led to a rise in popularity for BI tools such as BigQuery and Elasticsearch. These tools allow devs the opportunity to access the data without entering the production environment.

However, Situations Exist When Access Needs to be Direct

Although it’s prudent to follow the zero-trust approach, there are still times when it’s necessary for engineers to enter the production environment immediately, for example, during incidents. Without immediate access to fix things in production, problems can persist and the MTTR rises, resulting in lost time, lost resources and lost money. 

A few of examples are the following:

  • Incidents
  • Supporting customers
  • Maintenance and implementations
  • Integrations
  • Eliminating silos between developers and operations

Benefits of Automating Role and Permission Management for Databases

It’s clear there needs to be a solution to the chaos, and there are two approaches to achieve this. They are the following:

  1. One option is to transform it into a makeshift project that requires constant manual maintenance, involving the granting and revoking of permissions every time an individual joins or departs from the company, for example. This would result in a complicated and time-consuming endeavor, where a significant amount of time is wasted setting up permissions for all users. Clearly, this falls short of the ideal solution.
  1. The other option involves employing a flexible and fully automated system for role-based permission management that enables you to maintain a suitable balance between collaboration and control. This approach provides you with peace of mind, knowing that your data is secure and protected.

Problems with Manual Management of Database Permission Management

  1. Lack of Visibility. Apono provides centralized identity visibility so that teams can easily see each identity’s entitlements and permissions across all platforms. With this information, they can make informed decisions about which action to take.
  1. Not Secure. Standing permissions can introduce significant risk if not revoked when they are no longer needed, since they would provide an attacker with access if a user’s credentials are stolen. For organizations seeking to minimize their attack surface, mitigate the risk of data breaches, and ensure compliance, it is crucial to prioritize the reduction of accounts with standing privileges and transition towards a zero standing privilege framework.
  1. Bottlenecks. While we may have succeeded in decreasing complexity and increasing security by removing all access, we inadvertently introduced a bottleneck, restricting the number of individuals who can perform tasks on the database. The absence of self-service capabilities for developers will impede the release process, as it will rely on manual intervention from the database administrator (DBA) to implement necessary changes. This problem gives rise to numerous productivity challenges and effectively halts the CI/CD (Continuous Integration/Continuous Deployment) process whenever database-related tasks are involved.
  1. Static. Different situations call for different solutions, and permission management is no different. With dynamic authorization, you specify the authorization conditions and behaviors that govern each of your resources, including data stores, APIs, and applications. Conventional role-based access control (RBAC) lacks precision in the authorization process, while dynamic authorization offers a more intricate authorization service. Instead of relying on fixed permissions and role assignments to safeguard your resources, you can now configure policies that consider a wide range of attributes. By incorporating external attribute data, you can make highly detailed authorization decisions, placing a greater emphasis on context in the decision-making process. This context is evaluated for every resource request, enabling a tailored approach to authorization management that surpasses the coarse-grained nature of traditional authorization.

Benefits of Automated JIT Access to Databases

Just-in-Time access grants users just in time and just enough access to mission critical and sensitive databases. It eliminates the need for long-term privileged access for users and reduces the attack surface.

  1. Centralized Visibility. Database permissions are usually messy. We have zero visibility and too many passwords and permissions, making it difficult to know who has permissions to what. Having a centralized depository that automatically documents and manages user permissions is essential for post-mortem analysis.
  1. Time-restricted access. Automating the revoking of permissions after a specified time period assures there are no standing permissions that could be abused. 
  1. Tool Adoption. Company-wide tool adoption is just as important as what the tool does. If it’s not user-friendly, there will be friction. It’s important the tool fits in smoothly with the rest of the tool stack.

It is evident that when it comes to permission management for databases, we must establish order amidst chaos, and luckily there are ways to create a win-win permission management situation when it comes to provisioning database access.

Why F5 Permission Management Doesn’t Suck Anymore

Table of Contents

At Apono, we constantly hear from customers how difficult it is to set up granular permissions with F5, so we decided to dive in and see what’s so frustrating. We found a total of 6 issues. Check them out below.

Quick Overview: What is F5?

F5 is a company specializing in application security, multi-cloud management, online fraud prevention, application delivery networking (ADN), application availability & performance, network security, and access and authorization. 

Challenges of F5 Permission Management

  • Not flexible
    • Distributed workforces, rapid cloud adoption and a reliance on connected systems means that today sensitive data is copied, moved and shared to systems and collaboration tools that reside outside of the business. 

  • No internal auditing processes.
    • Legacy data permission practices and technology make it impossible to audit data permissions based on a business’s sensitive information and where it lives. As a result, system administrators struggle to stay on top of data access.

  • No way to generate temporary permissions on-demand.
    • Permissions are static, so any change needs to be done manually, which takes time and manpower.

  • Too many over-privileges 
    • For many companies, the quickest and simplest way to give out permissions is to just  assign a person the highest and widest access policies. 

  • Requires manual oversight to maintain.
    • Manual provisioning and de-provisioning of access is labor-intensive and prone to human error or oversight. It is not an efficient or sustainable way to manage user identities and access, especially for large enterprises.

  • Customer data not secure.
    • With the proliferation of over-privileged credentials, it’s easier than ever for attackers to gain access to secure information, which is why it’s important that permissions be temporary and limited in scope. 

  • Proxy-based.
    • F5 has a roof that allows you to set a workflow such as “this IP can access this IP,” which is too broad for granular-level access policies. 

Luckily, there are ways to overcome these obstacles. Read on below to find out how.

How Apono Makes F5 Permission Management Work

  1. Just-in-Time (JiT) Access. “Always-on” privileged accounts have long reigned as the default mode for administrative access. Today, these powerful, always-on accounts proliferate across enterprises. This means that the privileged access, rights, and permissions are always in an active mode and ready to be exercised—for legitimate activities as well as for illicit ones.

2. Automated Access Workflows. Setting up automatic workflows saves manual labor and time. They also allow for break-glass scenarios when needed, which decreases MTTR and downtime.

3. Self-Serve Permissions. Self-service access workflows allow you to create a process for your users to request access to datasets quickly and easily.

4. Resource-based access policies. Apono allows you to grant permissions to granular-level resources such as down to specific namespaces.

“Apono allows us to generate temporary permissions upon request on a very granular set of restrictions, delivering huge value to the business by reducing that Excel phase and optimizing the day-to-day work of multiple teams, including the R&D operations and security teams.”

As you can see, creating on-demand, granular-level permission access policies is impossible to do with just F5 alone. In order to benefit from JIT with F5, it’s imperative that you use a tool that can handle dynamic context. In other words, F5 permission management doesn’t have to suck anymore.

How To: Create Users and Grant Permissions in MySQL

Introduction to Permissions in MySQL

MySQL is a database application for Linux and part of the popular LAMP stack (Linux, Apache, MySQL, PHP). A MySQL installation includes options of managing through a root user or specific user accounts.

Managing user credentials in MySQL can be a time-consuming task, particularly when dealing with numerous MySQL instances spread across multiple servers. 

In this article, we’ll be reviewing how to do the following: 

  • How to create users in MySQL
  • How to grant user permissions in MySQL
  • How to revoke user permissions in MySQL

MySQL Databases and Users

Once you have MySQL installed on the server(s) that will host your MySQL environment, you need to create a database and additional user accounts. In order to run the following commands, log into the MySQL instance with the MySQL root account.

Create MySQL databases 

Creating a MySQL database involves a few simple steps. Here’s a step-by-step guide to creating a new MySQL database:

1. Create a New Database:

Now that you are connected to MySQL, you can create a new database using SQL commands. In the MySQL command-line client or phpMyAdmin, use the following SQL statement to create a new database (replace “Apono_database” with the desired name of your database):

  CREATE DATABASE Apono_database;

2. Verify the Database Creation:

To ensure that the database was created successfully, you can check the list of databases. In the MySQL command-line client, use the following command:

  SHOW DATABASES;

3. Use the New Database (Optional):

If you want to work with the newly created database, you need to switch to it using the following command in the MySQL command-line client:

  USE Apono_database;

That’s it! You have now successfully created a MySQL database. You can start creating tables and inserting data into it to build your application or manage your data. Remember to handle database credentials and access permissions with care to maintain security.

Create MySQL users

Creating a MySQL database involves a few simple steps. Here’s a step-by-step guide to creating a new MySQL database:

1. Install MySQL:

If you don’t have MySQL installed on your system, you need to install it first. You can download the MySQL Community Server from the official MySQL website: https://dev.mysql.com/downloads/

2. Start the MySQL Server:

Once you have MySQL installed, start the MySQL server. The process for starting the server varies depending on your operating system. On most systems, you can start the server using a command or by starting the MySQL service.

3. Connect to MySQL:

After the server is running, you need to connect to it using the MySQL command-line client or a graphical tool like phpMyAdmin.

– For the command-line client, open a terminal or command prompt and type:

  mysql -u root -p

  You will be prompted to enter the MySQL root password.

– For a graphical tool like phpMyAdmin, open a web browser and navigate to the phpMyAdmin URL. You can log in using your MySQL root credentials.

4. Create a New Database:

Now that you are connected to MySQL, you can create a new database using SQL commands. In the MySQL command-line client or phpMyAdmin, use the following SQL statement to create a new database (replace “Apono_database” with the desired name of your database):

  CREATE DATABASE Apono_database;

5. Verify the Database Creation:

To ensure that the database was created successfully, you can check the list of databases. In the MySQL command-line client, use the following command:

  SHOW DATABASES;

6. Use the New Database (Optional):

If you want to work with the newly created database, you need to switch to it using the following command in the MySQL command-line client:

  USE Apono_database;

That’s it! You have now successfully created a MySQL database. You can start creating tables and inserting data into it to build your application or manage your data. Remember to handle database credentials and access permissions with care to maintain security.

How to Grant Permissions in MySQL

To grant permissions in MySQL, you’ll need to have administrative privileges or the GRANT OPTION privilege on the database you want to modify. Here are the steps to grant permissions to a user in MySQL:

1. Connect to MySQL: Open a terminal or command prompt and connect to MySQL using a user account with administrative privileges. For example:

   mysql -u root -p

   You will be prompted to enter the password for the ‘root’ user or the administrative user you provided.

2. Select the database: If you want to grant permissions for a specific database, first select it using the following command:

   USE Apono_database;

3. Grant the permissions: Now, you can grant various privileges to the user using the `GRANT` statement. The basic syntax is as follows:

   GRANT privilege_type ON database_name.table_name TO 'user'@'host';

   Replace `privilege_type` with the specific privileges you want to grant. Here are some common privileges:

   – `SELECT`: Allows the user to read (SELECT) data from tables.

   – `INSERT`: Allows the user to insert new rows into tables.

   – `UPDATE`: Allows the user to modify existing rows in tables.

   – `DELETE`: Allows the user to remove rows from tables.

   – `CREATE`: Allows the user to create new tables or databases.

   – `DROP`: Allows the user to delete tables or databases.

   – `ALL PRIVILEGES`: Grants all privileges on the specified objects.

   Replace `database_name.table_name` with the specific database and table (or `*` for all tables) where you want to grant the privileges.

   Replace `’user’@’host’` with the username and the host from which the user will connect. For example, `’john’@’localhost’` refers to the user ‘john’ connecting from the same machine as the MySQL server.

   For example, to grant SELECT, INSERT, UPDATE, and DELETE privileges on all tables of a database called ‘exampledb’ to a user ‘exampleuser’ connecting from ‘localhost’, you would use the following command:

   GRANT SELECT, INSERT, UPDATE, DELETE ON exampledb.* TO 'exampleuser'@'localhost';

4. Apply the changes: After executing the `GRANT` statement, you need to apply the changes for them to take effect:

   FLUSH PRIVILEGES;

5. Exit MySQL: When you’re done granting permissions, exit the MySQL command line interface by typing:

   EXIT;

The user ‘exampleuser’ should now have the specified privileges on the ‘exampledb’ database or the specified tables within it. Make sure to grant the appropriate permissions based on your application’s requirements to ensure security and access control.

How to Revoke Permissions in MySQL

To revoke permissions in MySQL, you can use the `REVOKE` statement. This allows you to remove specific privileges from a user or role. Here’s how you can do it:

1. Connect to MySQL: Open a terminal or command prompt and connect to MySQL using a user account with administrative privileges. For example:

   mysql -u root -p

   You will be prompted to enter the password for the ‘root’ user or the administrative user you provided.

2. Select the database: If you want to revoke permissions for a specific database, first select it using the following command:

   USE Apono_database;

3. Revoke the permissions: Now, you can revoke specific privileges from the user using the `REVOKE` statement. The basic syntax is as follows:

   REVOKE privilege_type ON database_name.table_name FROM 'user'@'host';

   Replace `privilege_type` with the specific privileges you want to revoke. These should match the privileges you previously granted to the user. For example, if you previously granted SELECT, INSERT, UPDATE, and DELETE privileges, you would use the same list of privileges in the `REVOKE` statement.

   Replace `database_name.table_name` with the specific database and table (or `*` for all tables) from which you want to revoke the privileges.

   Replace `’user’@’host’` with the username and the host from which the user was connecting. For example, `’john’@’localhost’` refers to the user ‘john’ connecting from the same machine as the MySQL server.

   For example, to revoke SELECT, INSERT, UPDATE, and DELETE privileges on all tables of a database called ‘exampledb’ from a user ‘exampleuser’ connecting from ‘localhost’, you would use the following command:

   REVOKE SELECT, INSERT, UPDATE, DELETE ON exampledb.* FROM 'exampleuser'@'localhost';

4. Apply the changes: After executing the `REVOKE` statement, you need to apply the changes for them to take effect:

   FLUSH PRIVILEGES;

5. Exit MySQL: When you’re done revoking permissions, exit the MySQL command line interface by typing:

   EXIT;

That’s it! The user ‘exampleuser’ should no longer have the specified privileges on the ‘exampledb’ database or the specified tables within it. Make sure to carefully revoke only the permissions that are no longer necessary, to maintain proper access control and security.

Conclusion

You should now be able to create, modify, delete users and grant permissions in a MySQL database.

Remember, to improve security and limit accidental damage it’s important to limit users only to the privileges required for their jobs.

Check out our article about Just-in-Time Access to Databases. 

Permissions in MySQL

Enabling MongoDB Authentication Post-Setup

When enabling MongoDB Authentication post-set up, it’s important to do the following things if you want to avoid downtime.

Introduction: Productivity versus Security

Organizations must strike a balance between enabling employees to be productive and efficient while ensuring that access to sensitive information and resources is adequately protected. 

On one hand, productivity is crucial for organizations to remain competitive and achieve their goals. Employees need access to various systems, data, and tools to perform their tasks efficiently. Restricting access too much or implementing overly stringent security measures can hinder productivity and impede workflow.  

On the other hand, permission security is necessary to safeguard sensitive information, prevent unauthorized access, and mitigate the risk of data breaches or other security incidents. Organizations need to implement access controls, user permissions, and authentication mechanisms to ensure that only authorized individuals can access specific resources. These security measures help protect confidential data, intellectual property, and other critical assets from unauthorized use or disclosure.

Finding the right balance between productivity and permission security involves careful consideration and risk assessment.

Background: DB Access That is Not Authorized or Authenticated

When using a VPN or VPC, it’s easy to think that you don’t need any authentication or ways to enable authorization. After all, it is a private network. And, when it comes to productivity, manual provisioning takes time and needs constant oversight. It’s easy to see why so many companies choose to forgo security in favor of productivity. 

However, as these companies grow, they need to implement security measures and be compliant–all without interrupting productivity.

“Companies want to restrict access; they don’t want everyone to have access without a user password. Rather, companies want to make sure that people have different levels of access without hurting the R&D productivity.”

– Rom Carmel,
CEO and Founder, Apono

Method for Access Control: Adding User Passwords Post Set-up

For the many companies that didn’t set up authorization in MongoDB at the very beginning, it’s not too late. Setting it up after transitioning to the cloud is not impossible, but it does take some know-how. 

  • Identifying Your Users
    • To be able to identify who the user is, you first need the connection string to get the username and password for your database user. If there is none, you can create a new database user to obtain these credentials. 
  • Enabling Authorization in MongoDB
    • MongoDB does not enable access control by default. DBAs can enable authorization using the –auth or security.authorization setting. When you enable authentication, this also automatically enables client authorization. Enabling access control on a MongoDB deployment enforces authentication. With access control enabled, users and applications are required to identify themselves and can only perform actions that adhere to the permissions granted by the roles assigned to their user.
MongoDB Authentication
  • Enabling MongoDB Authentication
    • Enabling authentication in MongoDB is necessary for user passwords to be recognized and read. But once you enable it, you’re breaking the way that everything works today, such as accessing MongoDB without a username or password.

Problem: MongoDB Authentication Breaking the Way Everything Works.

It’s not only people who need to access MongoDB to be affected; it’s also applications. So, in effect, none of the applications can access that MongoDB either.

Enabling authorization post-set up will break how teams work unless it’s done smartly.

How We Solved the Transition to MongoDB Authentication

It’s important to run the mongoDB with TransitiontoAuth enabled, which allows for accepting of  both authenticated and unauthenticated connections. Clients connected to the mongoDB during the transition state can perform read, write, and administrative operations on any database, so it’s important to remember to disable the feature after transitioning. 

This transition puts the company in an in-between state that allows access two ways: ones with user password connection strings and ones without. So, essentially you’re not really restricting any access because you can access it also without the user password. However, you are now starting to log and can therefore see who  hasn’t moved to using a password yet.

“You don’t want to just disable it before you’ve seen that all the people and applications who use and access that MongoDB have shifted to moving to working the new way.”

Rom Carmel

Conclusion: When in transit mode you should start working with Apono

Without Apono, it’s necessary for companies to create their own users and their own policies to these. But with Apono, they don’t need to do that. They can ask for what they need, and it’s automatically granted. How? When someone asks permission for a user, Apono goes inside the Mongo, creating a policy that will fit those needs, and giving the requestor a user. Then that user can be utilized to connect the model when the authentication is turned off. 

What We Learned at KubeCon Europe

Our team had an amazing time at Kubecon Amsterdam, connecting with DevOps and developers from around the world and showcasing our permissions management automation platform—Apono. 

We were thrilled to see the excitement and interest in our solution, as attendees recognized the need for better permission management in their organizations—from a security, time-saving and compliant perspective.

In addition to showcasing Apono at the conference, we also held several technical sessions to help attendees learn how to automate permission management. These sessions covered a range of topics, from gaining access visibility in K8s clusters to creating incident response access flows for on-call groups.

A few take-ways from our team at Kubecon:

“I realized that even a developer can sell when his product brings real value.”

Dima – Software Team Lead @ Apono

“I learned that the best way of getting someone attention is with a nerf-gun, hacky sacks and old-school arcade games – I’m definitely in the right industry” 

Roey – Head of Marketing @ Apono

“I discovered that everyone needs Apono, it does no matter if it is a big company or small, as long as you need to keep your customer data safe, you will need JIT permissions to all your cloud assets, DBs, K8s, and R&D applications.”

Tamir – Senior Director of Technical Services @ Apono

“I learned that you can put thousands of developers in one room and no tragedy will happen. Also, there is no such thing as too many socks!”

Ofir – CTO & Co-founder @ Apono

“Kubernetes is everywhere and permissions in K8s is a tedious thing to manage, especially when trying to do it “right” and granular. Even just understanding who has what permissions in a cluster is not as straightforward as one might think”

Rom (CEO & Co-founder @ Apono)

Workshop in the conference – Apono at Kubecon Europe

Overall, Kubecon Amsterdam was a fantastic opportunity to meet like-minded individuals who share our passion for innovation for k8s in the cloud-native space. 

We look forward to continuing to develop solutions that help organizations better manage their cloud environments and improve their security posture.

Temporary Access To Cloud SQL

CloudSQL Access Controls

Securing the development environment is a critical challenge for DevSecOps teams that must navigate multiple cloud environments and technologies. To improve collaboration between developers, security professionals, and IT operations staff, we need to provide secure access to physical networks and services—which often include providing elevated levels of permissions for databases such as CloudSQL. Ultimately, you should come away with an understanding of how to securely grant developers increased privileges in their public cloud Cloud SQL environments without sacrificing any security posture or control.




Managing Permissions in CloudSQL

This blog post will explore how to efficiently manage secured elevated permissions to Cloud SQL, an enterprise database service offered on Google Cloud Platform. With Apono strategies, you can make sure that only those who need it have access to the right information while minimizing both project overhead and organizational risk. Let’s dive in!




Using Apono To Provide Temporary Access to CloudSQL

Your first step in create an Apono account, you can start your journey here.

Follow the steps at our CloudSQL Integration Guide.

Now that Apono is set you can start creating Dynamic Access Flows:

  • Automatic Approval Access Flows – Using admin defined context and pre defined role to provide automatic access to CloudSQL resources.
  • Manual Approval Access Flows – Using admin defined context and pre defined role to provide automatic access to CloudSQL resources.



Using Apono declarative access flow creator you will be able to simply define:

  • Approvers
    • User Group (round-robin)
    • Single User
    • Automatic – Contextual
  • Requesters
    • User Group
    • Single User
  • Resource
    • Single Resource
    • Pre-Defined Resource Group
    • Partition of a resource
  • Duration
    • By Hours
    • By Days
    • Infinite

Example: Cloud SQL Automatic Approval Access Flow:

Temporary Access To CloudSQL

Example: Cloud SQL Manual Approval Workflow:

Temporary access to Cloud SQL allows you to specify a predetermined period during which certain IP addresses or IP ranges are permitted to connect to the database. Once the defined duration expires, access to the instance is automatically revoked.

The temporary access feature is particularly beneficial when you require short-term access for specific purposes, such as granting temporary database privileges to third parties or clients. By employing temporary access, you can avoid the need to permanently add unfamiliar IP addresses to the instance’s authorized network list, bolstering the overall security of your Cloud SQL deployment.

The duration of temporary access can be customized to meet your requirements, ensuring that connectivity is available for an extended period. This flexibility allows you to accommodate projects or collaborations that demand longer-term access to your Cloud SQL instance. Once the designated period concludes, the system will automatically remove the authorized access, safeguarding your database from unauthorized connections.


Streamlined Access. Frictionless Security.

With Apono, companies satisfy customer security requirements and dramatically reduce attack surfaces and human errors that threaten commerce. Apono liberates DevOps teams to deliver more for customers and the businesses without delay.

Temporary Access To PostgreSQL

PostgreSQL Access Controls

PostgreSQL is a widely popular relational structured database management system, PostgreSQL authorization is an ongoing process that checks each command, comparing it with the users account role and its associated privileges.




Managing Permissions in PostgreSQL

In the era of DevSecOps, ease of access and secure management of resources is essential to facilitating collaboration among development teams. Providing developers with elevated access to PostgreSQL can be a critical step in speeding up product development cycles while maintaining necessary security protocols. For an organization that has many users accessing different databases, granting individual user accounts exclusive privileges can be cumbersome and overwhelming. With this blog post, we will explore best practices involved in setting up privileged PostgreSQL accounts for developers while protecting core assets from unauthorized or careless use.




Using Apono To Provide Temporary Access to PostgreSQL

Your first step in create an Apono account, you can start your journey here.

Follow the steps at our PostgreSQL Integration Guide.

Now that Apono is set you can start creating Dynamic Access Flows:

  • Automatic Approval Access Flows – Using admin defined context and pre defined role to provide automatic access to PostgreSQL resources.
  • Manual Approval Access Flows – Using admin defined context and pre defined role to provide automatic access to PostgreSQL resources.



Using Apono declarative access flow creator you will be able to simply define:

  • Approvers
    • User Group (round-robin)
    • Single User
    • Automatic – Contextual
  • Requesters
    • User Group
    • Single User
  • Resource
    • Single Resource
    • Pre-Defined Resource Group
    • Partition of a resource
  • Duration
    • By Hours
    • By Days
    • Infinite

Example: PostgreSQL Automatic Approval Access Flow:

Temporary Access to PostgreSQL

Example: PostgreSQL Manual Approval Workflow:


Streamlined Access. Frictionless Security.

With Apono, companies satisfy customer security requirements and dramatically reduce attack surfaces and human errors that threaten commerce. Apono liberates DevOps teams to deliver more for customers and the businesses without delay.

Temporary Access To MySQL

Temporary Access to MySQL – Apono Access Automation

Intro

MySQL is a widely popular relational structured database management system, MySQL authorization is an ongoing process that checks each command, comparing it with the users account role and its associated privileges.




MySQL Access Controls

For many DevOps professionals, managing secure access to the company’s databases is a challenging task. You need to manage user permissions and authentication, as well as inevitable requests for temporary access for staff members and third-party vendors. These requests create an additional burden on your team, but ensuring controlled access to MySQL can be a straightforward process if you know how to do it correctly. In this blog post, we’ll discuss best practices for granting temporary MySQL access in an efficient and secure manner using Apono. We’ll talk about why it’s important that Temporary Access is properly managed, guidelines on which users should receive temporary credentials and how long the temporary credential should remain active for.




Using Apono To Provide Temporary Access to MySQL

Your first step in create an Apono account, you can start your journey here.

Follow the steps at our MySQL Integration Guide.

Now that Apono is set you can start creating Dynamic Access Flows:

  • Automatic Approval Access Flows – Using admin defined context and pre defined role to provide automatic access to MySQL resources.
  • Manual Approval Access Flows – Using admin defined context and pre defined role to provide automatic access to MySQL resources.



Using Apono declarative access flow creator you will be able to simply define:

  • Approvers
    • User Group (round-robin)
    • Single User
    • Automatic – Contextual
  • Requesters
    • User Group
    • Single User
  • Resource
    • Single Resource
    • Pre-Defined Resource Group
    • Partition of a resource
  • Duration
    • By Hours
    • By Days
    • Infinite

Example: MySQL Automatic Approval Access Flow:

Example: MySQL Manual Approval Workflow:



Streamlined Access. Frictionless Security.

With Apono, companies satisfy customer security requirements and dramatically reduce attack surfaces and human errors that threaten commerce. Apono liberates DevOps teams to deliver more for customers and the businesses without delay.

How streamlining access leads to productive development teams

Does your access management hurt your team’s productivity? It does.

How do we know? Let’s look at the data.

Access and productivity in numbers

The average employee has 191 passwords to keep track managing all those different usernames and passwords is a huge time suck. There’s no denying it: having to constantly remember a jumble of passwords is a productivity killer. A recent study found that the average employee spends over 10 hours in their work year simply inputting passwords. Add to that the time required to reset forgotten passwords, and you’re looking at a serious drag on productivity: the estimated cost of lost productivity per organization averages $5.2 million annually.

But it’s not just the time spent managing passwords that hurts productivity—it’s also the time spent waiting for access to the systems and data your team needs to do their jobs. In fact, 66% of employees say they’ve wasted time at work waiting for someone to give them access to something. And one-third of technical employees of IT professionals say that restrictive access causes daily (31.8%) and weekly (32.3%) interruptions in their work.

These interruptions quickly snowball into missed deadlines and frustrated workers. 52% of development teams have missed deadlines due to a lack of access to the needed resources and infrastructure.

For example, imagine this common scenario: a developer needs to access a Kubernetes cluster to work on an application, but they can’t log in. Their manager, who normally provides access, is on PTO abroad with spotty reception. They have no choice but to send a request up the chain manually and hope for the best, which results in losing hours or even days on a project simply waiting for access to a resource.

If this sounds familiar, your company isn’t alone—in fact, 64% of businesses have experienced financial losses due to access management issues. Missed deadlines and extended projects often result from inefficiencies in access management.

And it’s not just the users who are affected: help desk employees spend nearly 30% of their time resetting passwords. That’s valuable time that could be spent on other tasks.

Access and security in numbers

A record number of data breaches in 2021—1,862 to be exact—cost companies an average of $4.24 million each. According to Verizon, 61% of all company data breaches and hacking incidents result from stolen or compromised passwords, and it’s not hard to see why.

When employees lack seamless access to systems, it not only affects productivity but also company security. 

Technical employees need access to do their job well, but they’re not always given that access. To do their jobs, technical teams often find creative ways around the access roadblocks by resorting to methods such as password reuse, shadow IT, sharing credentials, or keeping backdoor access. In other words, when employees can’t get the access they need to do their job, they find ways to get it themselves—even if that means going around company policy.

These workarounds might help the technical team finish their tasks and knock down some Jira tickets in their queue, but it also exposes the company to security risks. A recent study found that 8 out of 10 hacking incidents were due to shared passwords, and even more alarmingly, 53% of employees have admitted to sharing their credentials.

Passwords are proliferating across our digital world and getting stolen in record numbers every year. Consequently, it’s no mystery that over 555 million passwords are accessible on the Dark Web, leading to credential-stuffing attacks that account for a majority of data breaches in recent years.

Streamlined access is key to both productivity and security

The bottom line is this: if you want to improve productivity and security, you need to give your technical teams seamless access they need to do their job.

Now that we’ve established that access is key to productivity and security, let’s look at how you can streamline access and get your team back on track.

That’s where Apono comes in. 

Apono.io is an innovative identity and access management solution that gives your technical teams the access they need — without sacrificing security.

Apono streamlines access by automating the process of granting and revoking permissions, so you never have to worry about manually managing access again. Our technology discovers and eliminates standing privileges using contextual dynamic access automation that enforce Just-In-Time and Just-Enough Access.

Streamlining access also makes it easier to meet auditing and compliance requirements. With Apono, you can see who has access to what, when they accessed it, and from where.

With Apono, It is now possible to seamlessly and securely manage permissions and comply with regulations while providing a frictionless end-user experience. Plus, Apono integrates with popular applications like Jira, Slack, and Google Workspace, so you can manage access from one central location.

With Apono.io, you can:

  • Automatically grant and revoke access for a seamless user experience
  • Enforce least privilege and separation of duties for better security
  • Monitor user activity and ensure compliance

And much more!

It’s simple to use and easy to set up, so you’ll be up and running in no time. Stop wasting time on access issues and start improving productivity—and security—with Apono.io today.

DevOps Expert Talks: Ask Me Anything With Moshe Belostotsky

In this Q&A session with Moshe Belostotsky, Director of DevOps at Tomorrow.io, we dive into the changing role of DevOps and how security considerations are changing the way software is being built and delivered.

Q: First of all, if you can tell me a little about yourself, what brought you into DevOps?

A: “I was in the world of DevOps even before it was called DevOps and before the Cloud became a thing. Ever since I can remember, I have been doing automation, CI/CD, treading this line between infrastructure automation and enablement, automatic tests, and later on, the Cloud.

I started working with automation at the age of 16 and have been doing it ever since with a 4-year break during my army service, after which I jumped right back in.

Q: What do you like the most about working with DevOps automation?

A: “A couple of things.

First, it’s the variety of work: the number of touch points with the platform, with the different teams, and sometimes with the customers. At its core, DevOps is about collaboration. It’s about breaking down silos between development and operations teams so that they can work together to deliver software faster and more efficiently.

Second, it’s never-ending problem-solving. You are always looking for ways to optimize processes, increase the velocity and optimize the way developers work. It’s also about the efficiency and stability of the production environment.

In a way, being in DevOps allows you to see a bird’s eye view of the entire system. What makes this role very interesting is not being limited to a single domain.

Q: What advice can you give to somebody who is just starting in DevOps?

A: “As an autodidact, I can say that the first thing to know is that you don’t know anything. That’s the baseline and the starting point. And the second thing to realize is that you can solve anything.

Once you know that everything is solvable and that you don’t need to panic when you don’t know how to solve something because you can always gather new knowledge, you can start enjoying the process of problem-solving and optimizing.”

And last but not least, understanding the developers and how they think, and how we can add value by translating the infrastructure to them.”

Q: What do you think makes a good DevOps engineer?

A: “A person with a can-do attitude, a people person, who is always learning, and a problem-solver.

Someone who has that basic understanding that everything is solvable and that we should not take for granted anything at all. Someone who strives to help the developers and understands that we’re here to communicate with people and solve their problems, not just communicate with the computers.”

Q: As a director of DevOps, what are your priorities?

A: “MTTR, MTBF, and LTV, so mean time-to-value, mean time between failures, and mean time to recovery. Those are the measurable KPIs to focus on. And, of course, cost efficiency.”

Q:  As a DevOps leader in your organization, what role does security play in the decisions you make?

A: “Very important. I work closely with the security team.

Collaboration is key. As DevOps, we need to create a single language with the security office. Because eventually, we aim for a single goal – for the company to be successful, to grow, and to avoid security incidents, especially public incidents. These will undeniably be very bad for the company and very bad professionally for all involved. We never want to be in this situation.

But also an important part of DevOps is the developer experience. So when we apply security measures and security restrictions on production environments, we still need to maintain the mean time-to-value KPIs.

So when the developers can’t do their work or have to go a much longer road when trying to achieve their goals, we hurt the company, although we increase security.

If the developer cannot view his environment in production, you cannot access these environments in production, doesn’t have any breaking glass protocol, the recent environment in production, then we hurt mean time to value, and mean time to recovery, which eventually will hurt the company. Although our security is great, we will be out of business.

So balancing developer experience with security is something we constantly have to focus on as DevOps.

Q: As DevOps, what’s the worst ask you get from other teams?

A: “Friday afternoon, a developer decided that he has some spare time to develop. He encounters an issue, and he’s starting to send messages in the DevOps channel.

The channel has two functions; we use it both for standard requests and for urgent requests. So we are always monitoring those channels. And those requests, especially when they’re ambiguous but turn out to be non-urgent, should really wait till Monday morning.”

Q: How can organizations assist their DevOps engineers to be more successful in their jobs?

A: “First is creating the space for and facilitating learning. Most of the DevOps teams are understaffed. And we don’t have time for learning, upskilling, going to meetups, and taking courses. To make the learning part of the job description.”

Q: What would you think is the next big change in DevOps?

A: “I think the two trends to be aware of are serverless and shift-left.

DevOps will require more and more coding skills. We will need to do more and more coding and less infrastructure maintenance. That is why we in DevOps always need to learn and adapt.”

Moshe Belostotsky is the Director of DevOps at Tomorrow.io. With nearly two decades of experience in the field, Moshe is one of the leading minds in the startup nation’s DevOps community. Having worked with companies such as Cisco, Hewlett-Packard, and Fiverr,  Moshe has a wealth of experience in the field. In his current role at Tomorrow.io, he is responsible for managing the entire DevOps department and ensuring that the company’s products are released on time and meet customer expectations. In addition to his role at Tomorrow.io, Moshe is the in-demand thought leader in the DevOps community and frequently speaks at industry events.