【问题标题】:Google KMS on AppEngine/Python & Development AppServerAppEngine/Python 和开发 AppServer 上的 Google KMS
【发布时间】:2017-06-29 13:45:04
【问题描述】:

the documentation 不清楚如何使用 Google App Engine Standard 上的 Google Key Management System (KMS),尤其是在使用开发服务器进行本地开发时。

它看起来相当简单:

  1. 在 Python 虚拟环境中安装google-api-python-client(并在appengine_config.py 中添加带有google.appengine.ext.vendor 的虚拟环境路径)
  2. 正在导入googleapiclient.discovery
  3. 使用google.appengine.api.app_identity 获取应用程序标识
  4. 以预期/记录的方式使用 kms 客户端

...然后按照文档中链接的教程进行操作。但是,到目前为止,我的尝试并没有成功,而且文档似乎还需要几个步骤。

感觉就像我正在开辟新天地,我相信其他人一定已经拥有了。

是否有人记录在 App Engine Standard 及其本地开发服务器上使用 Google KMS?

编辑 - 使用代码示例更新

这里有一些代码说明问题 - 问题似乎与我设置的默认凭据有关。

mykms.py

import googleapiclient.discovery
from google.appengine.api import app_identity

from oauth2client.client import GoogleCredentials
credentials = GoogleCredentials.get_application_default()

PROJECT = 'my-crypto-project'
IS_LOCAL = True
LOCATION = 'global'
TESTING_KR = 'testing-keyring'
KEY_RING = TESTING_KR if IS_LOCAL else app_identity.get_application_id()

kms = googleapiclient.discovery.build('cloudkms', 'v1', credentials=credentials)

def encrypt(plaintext, cryptokey, keyring=KEY_RING, location=LOCATION):
    name = 'projects/{}/locations/{}/keyRings/{}/cryptoKeys/{}'.format(
        PROJECT, location, keyring, cryptokey
    )
    cryptokeys = kms.projects().locations().keyRings().cryptoKeys()
    request = cryptokeys.encrypt(name=name, body={'plaintext': plaintext})
    return request.execute()


def decrypt(ciphertext, cryptokey, keyring=KEY_RING, location=LOCATION):
    name = 'projects/{}/locations/{}/keyRings/{}/cryptokey'.format(
        PROJECT, location, keyring
    )
    cryptokeys = kms.projects().locations().keyRings().cryptoKeys()
    request = cryptokeys.decrypt(name=name, body={'ciphertext': ciphertext})
    return request.execute()

现在通过dev_appserver.py拨打电话:

import mykms
mykms.encrypt("my text", cryptokey="my-key-ring")

给出一个错误:

HttpError: https://cloudkms.googleapis.com/v1/projects/np-crypto/locations/global/keyRings/localhost-testing/cryptoKeys/machine-identifiers:encrypt?alt=json 返回“请求的身份验证无效凭据。需要 OAuth 2 访问令牌、登录 cookie 或其他有效的身份验证凭据。请参阅 https://developers.google.com/identity/sign-in/web/devconsole-project。">

这并不是特别有用,主要关注网站上的 Google 登录;但是,当我从命令行导入 mykms 时,出现错误:

应用程序默认凭据不可用。如果在 Google Compute Engine 中运行,它们就可用。否则,必须定义环境变量 GOOGLE_APPLICATION_CREDENTIALS 指向定义凭据的文件。请参阅https://developers.google.com/accounts/docs/application-default-credentials 了解更多信息。

目前看来,这似乎是正确的线索。将其清除并报告回来。

编辑#2

应用程序现在似乎已连接到 KMS。我删除并重新登录gcloud auth application-default login

但是,有一个奇怪的副作用 - 似乎有东西正在扫描驱动器,并且有数百条消息(似乎每个可从根目录访问的目录都有一条消息),如下所示:

INFO 2017 年 6 月 30 日 20:06:57 沙盒阻止访问文件“/Users”

INFO 30 Jun 2017 20:06:57 如果是静态文件,请检查您的 app.yaml 中是否设置了application_readable: true

【问题讨论】:

  • 我正在尝试理解您的问题。 AppEngine 开发环境中没有 KMS,因此无论您的客户端是在 dev_appserver 本地运行还是在 App Engine 中运行,您都必须与 GCP 上运行的 Cloud KMS 通信。因此,您可能需要做两件事:首先,您需要一种从 dev_appserver 进行身份验证的方法,并了解如何更改该方法以在 App Engine 上运行时进行身份验证。其次,您需要考虑是否会在开发和生产中使用不同的密钥。其中哪一个是您最关心的?还是两者兼而有之?
  • @TimDierks 谢谢。主要问题是设置不起作用。我确定这是一个配置问题,这意味着真正的问题是找到一个能够说明所需设置的样本。目前的问题(在解决了其他几个问题之后)是 dev_appserver 没有正确使用 KMS 的登录凭据 - 即使它们使用远程 api 和 gcloud(包括加密/解密),它们也不起作用在 KMS 的 dev_appserver 中(即身份验证失败,即使我的帐户特别具有访问权限)。我想我想看看一个可行的例子。
  • @TimDierks 主要问题是我必须使用应用程序默认值重新进行身份验证(可以说问题是/是缺乏关于该/为什么身份验证失败的反馈)。这里有一个与日志记录相关的问题:stackoverflow.com/q/44888563/19212

标签: python google-app-engine google-app-engine-python google-cloud-kms


【解决方案1】:

如果您在 GAE 中使用 Cloud KMS 进行开发,则没有本地开发服务,您只能与收集到的主要生产服务进行对话。您可以使用您详述的库在本地进行开发,但仍会投入生产。

请注意,您必须为 GAE 应用程序提供默认凭据以及使用范围,请参阅https://cloud.google.com/kms/docs/accessing-the-api#google_app_engine

如果您使用 GAE 服务帐户,您也可以提出请求 gcloud iam service-accounts keysgcloud auth activate-service-account

一般来说,对于开发环境,您可能希望将其从生产资源中分割为单独的 KeyRing(甚至是单独的项目)。

【讨论】:

  • 谢谢玛雅。这有帮助,我现在正在关注实施。我认为一个理想的答案会显示一个示例 AppEngine(标准)项目和设置,我会发布任何关于我所做工作的注释,并在我弄清楚时标记这个答案是正确的。 :)
  • 必须重新登录应用程序默认帐户(这可能有助于记录其他人的故障排除),顺便提一下related logging question,我将其标记为正确。跨度>
猜你喜欢
  • 2017-12-06
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-06-09
  • 2014-10-22
  • 1970-01-01
  • 2023-04-06
  • 1970-01-01
相关资源
最近更新 更多