Управление областью учетных данных с помощью учетных записей служб

Легко создавайте и отзывайте учетные данные для ролей и баз данных.

На прошлой неделе мы представили большую новую функцию на bit.io: сервисные аккаунты. Учетная запись службы позволяет ограничить объем разрешений базы данных, которые вы предоставляете приложениям, службам и инструментам. В то время как ваша личная учетная запись имеет полные и неограниченные права на чтение/запись/администрирование всех ваших баз данных, область действия служебной учетной записи может быть ограничена определенными разрешениями (такими как чтение/запись). только) и определенное подмножество баз данных.

Все это можно сделать всего за несколько кликов: не нужны CREATE ROLEs; нет операторов GRANT; Нет я; никаких головных болей. Служебные учетные записи просты и эффективны. Нет необходимости часами изучать документацию, чтобы понять, как управлять разрешениями и безопасностью на bit.io.

Вы можете прочитать все о том, как использовать сервисные аккаунты (в минутах, а не в часах) в нашей документации. Здесь мы поговорим о том, почему вам следует использовать сервисные аккаунты, а затем рассмотрим несколько примеров использования.

Почему сервисные аккаунты?

Учетные записи служб позволяют пользователям следовать принципу наименьших привилегий, который гласит, что данный пользователь/служба/инструмент/и т. д. должен иметь доступ только к минимальному набору привилегий и ресурсов, необходимых для достижения данной цели. Это имеет несколько преимуществ:

• Безопасность. Если приложение имеет доступ только для чтения к базе данных, нет риска, что его учетные данные могут быть использованы для записи или удаления из базы данных, даже если эти учетные данные скомпрометированы.
• Сложность. Ограничение объема привилегий/ресурсов может снизить сложность за счет ограничения действий, доступных для разных приложений или частей приложения. Нет необходимости контролировать возможность записи приложения в базу данных, если приложение имеет доступ только для чтения.
• Разделение привилегий. Предоставление отдельных учетных данных разным приложениям или частям приложения по отдельности позволяет отзывать определенные учетные данные по мере необходимости. Выполнено с использованием определенного инструмента? Отозвать его сервисный аккаунт. Беспокоитесь о том, что конкретный ключ API просочился? Отзовите это. Вам не нужно будет менять ключи API для каждого приложения/каждой части вашего приложения — они отдельные и могут быть отозваны по отдельности.

Обратите внимание, что сервисные аккаунты не предназначены для совместного использования ваших баз данных с другими пользователями. Существующее меню «Поделиться» по-прежнему является местом для обмена вашими данными. Меню «Поделиться» также обеспечивает контроль над областью — вы можете предоставлять разным пользователям разные уровни доступа к разным базам данных и отзывать этот доступ по мере необходимости. Когда вы предоставляете общий доступ к базе данных из меню общего доступа, человек, с которым вы предоставили общий доступ, использует свои учетные данные для доступа к общим данным. Это также может иметь последствия для выставления счетов: запросы, сделанные учетной записью службы, будут отнесены к вашей учетной записи, тогда как запросы, сделанные кем-то, с кем вы поделились данными, будут отнесены к учетной записи этого пользователя.

Вариант использования: тестирование данных

Мы ранее писали о тестировании данных в конвейерах ETL, которые могут позволить нам, например, обнаруживать недопустимые записи, сдвигающие распределения, крайние случаи или другие неожиданные результаты. Как правило, этот тип теста не требует доступа для записи! Мы можем создать учетную запись службы для тестирования данных. Предположим, мы хотим запустить некоторые тесты данных на одной из таблиц для Праздничного курса SQL (посмотрите, если вы только начинаете работать с SQL!). Мы можем создать учетную запись службы только для чтения специально для тестирования:

На снимке экрана выше мы создали учетную запись службы только для чтения, предназначенную специально для базы данных InnerJoin/sqlholiday. Чтобы использовать эту учетную запись службы, нам нужно создать ключ API. Мы можем сделать это в один клик:

Теперь, если мы вернемся на вкладку sqlholiday подключения к базе данных, у нас будет полный набор учетных данных для доступа, связанных с новой учетной записью службы, поэтому мы можем подключиться к базе данных, используя эту учетную запись службы.

Итак, давайте напишем тест! Одна из таблиц базы данных содержит данные Palmer Penguins, которые включают в себя различные измерения пингвинов, в том числе массу тела в граммах. Предположим, у нас есть некоторые базовые знания о пингвинах с этих островов и мы уверены, что все они весят менее 50 кг (50 000 г). Мы можем написать тест, который завершится ошибкой, если встретит запись с большим весом. Мы сделаем это с помощью очень простого скрипта Python, который подключается к базе данных с помощью служебной учетной записи sql_holiday_test.

import pandas as pd
import os
from sqlalchemy import create_engine
from dotenv import load_dotenv

load_dotenv()

PG_STRING = os.getenv("SERVICE_ACCOUNT_PG_STRING")


# Return SQL query as a pandas dataframe
def get_penguin_df(PG_STRING):
    """queries the database and returns the penguins table as a Pandas dataframe"""

    engine = create_engine(PG_STRING, pool_pre_ping=True)
    # SQL for querying an entire table
    
    sql = f'''
        SELECT *
        FROM penguins;
    '''
    with engine.connect() as conn:
        df = pd.read_sql(sql, conn)
    return df

# test penguin weight
def penguin_weight_test(df):
    """checks that none of the penguins in the dataset weigh more than 50,000 g"""
    if (df['body_mass_g'] >= 50000).any():
        raise Exception("Test Failed!")
    else:
        print("Test Passed! All penguins in the dataset weigh less than 50kg.")

if __name__ == "__main__":
    df = get_penguin_df(PG_STRING)
    penguin_weight_test(df)

Который возвращает, как мы и ожидали:

Test Passed! All penguins in the dataset weigh less than 50kg.

Предположим, мы пытаемся удалить таблицу пингвинов, используя эти учетные данные:

import os
from dotenv import load_dotenv
import psycopg2

load_dotenv()

PG_STRING = os.getenv("SERVICE_ACCOUNT_PG_STRING")

if __name__ == "__main__":
    try:
        conn = psycopg2.connect(PG_STRING)
        with conn.cursor() as curs:
            curs.execute("DROP TABLE penguins")
    except psycopg2.Error as e:
        print(e)

Запуск этого возвращает:

Permission Denied
DETAIL: You do not have permission to run this DROP command
HINT: Contact a database admin to get permission

Вариант использования: отзыв скомпрометированных учетных данных

О, нет! Мы случайно опубликовали наш файл .env с учетными данными нашей учетной записи службы тестирования в общедоступном репозитории Git. Весь проект скомпрометирован? Нужно ли нам менять учетные данные для каждой части проекта?

Нет! Прежде всего, используя учетную запись службы, мы гарантировали, что в самом худшем случае кто-то получит доступ для чтения к одной таблице. Это преимущество разделения привилегий, о котором мы говорили выше. И, как мы показали в предыдущем разделе, любой, кто попытается использовать учетные данные сервисной учетной записи только для чтения для удаления данных, столкнется с ошибками.

Во-вторых, мы можем отозвать ключи, связанные с этой учетной записью службы, чтобы никто из тех, кто мог получить скомпрометированный ключ, не имел доступа к данным. Мы можем отозвать все ключи, связанные с учетной записью службы; отозвать один ключ (если у нас есть конкретный скомпрометированный ключ) или удалить всю учетную запись службы.

После выполнения любого из этих действий непреднамеренный доступ к данным через скомпрометированный ключ будет невозможен.

Твой ход

При интеграции bit.io со сторонним инструментом, создании приложения, написании тестов и т. д. мы рекомендуем использовать сервисные учетные записи вместо ваших личных учетных данных. Учетные записи служб позволяют вам предоставлять минимальные необходимые разрешения для текущей задачи.

Вы также можете программно создавать и отзывать ключи API личного или сервисного аккаунта, используя наш API разработчика. В зависимости от приложения может быть выгодно автоматизировать создание/отзыв учетных данных служебной учетной записи.

Узнайте больше о том, как их использовать, в нашей документации: https://docs.bit.io/docs/service-accounts