Confluent has something called Audit Logs which are written to internal topics (if configured) and which log access to Kafka resources such as clients writing or reading from particular topics. That's all great, however, there are components in a Confluent/Kafka setup such as Confluent Control Center which (should) have a RBAC access set up for users to log in and use.
It is possible to set it up and have users log in with username and password but I am having difficulties in locating where exactly Confluent provides logs of successful/unsuccessful login attempts. If I set the Control Center logs to DEBUG, I can see the HTTP communication and the password lookup for when a user tries to login but I don't see an option for admin review and control of such events. Audit Logs are apparently only for Kafka resources. Is there no other option other than building up a custom solution, scraping DEBUG logs?
The list of auditable events is documented here. Confluent Control Center login events are unfortunately not one of them.
Related
Is there a way in ActiveMQ Artemis to create users and roles dynamically from code or is calling shell command artemis or artemis.cmd the only way?
Edit: Also, is there a way to list and delete users and roles?
The CLI commands use the management API to add, list, remove, and reset users. The management API is accessible in many different ways. For example, if your broker is embedded you can invoke the management API directly. If your broker is remote you could use JMX (either administratively or programmatically, programmatic example here), HTTP (via Jolokia), or management messages (example here).
I am using LDAP as User federation for my Keycloak instance. Is there a supported way to monitor LDAP events like syncErrors/successfulImports, userUpdates and etc? Preferably
through Prometheus metrics endpoint. Im aware of "aerogear/keycloak-metrics-spi" extension, but looks like it doesnt expose any metrics related to user federation.
If I understand Keycloak monitoring innerworks correctly, Keycloak should be issuing user federation related "events". When I inspect available events at documentation there seems to be only 4 events that resemblence what Im looking for (see image attached). But even these events are not enough for me.
Our infrastructure is hosted on Google Cloud and uses postgresql instances via Cloud SQL
I need to configure logging for HIPAA compliance.
I have read 2 articles from Google's documentation:
https://cloud.google.com/logging/docs/audit/configure-data-access#config-console
https://cloud.google.com/sql/docs/postgres/pg-audit#overview
The first talks about enabling Audit Logs from within IAM, here I can select Cloud SQL and enable r+w logs for data and admins
The second talks about PgAudit and sets the following flag pgaudit.log=all
I have a couple of questions:
How do IAM logs and PgAudit differ, should I enable both or is there redundancy by doing so?
For HIPAA compliance using PgAudit, should I log all or is there another value that makes sense
How do IAM logs and PgAudit differ, should I enable both or is there redundancy by doing so?
Well the IAM Logs focus on Admin Activity and data access:
Admin Activity audit logs: Includes "admin write" operations that
write metadata or configuration information.
Data Access audit logs: Includes "admin read" operations that read
metadata or configuration information. Also includes "data read" and
"data write" operations that read or write user-provided data.
On the other hand the pgAudit extension applies to executed SQL commands and queries.
Basic statement logging can be provided by the standard logging
facility with log_statement = all. This is acceptable for monitoring
and other usages but does not provide the level of detail generally
required for an audit. It is not enough to have a list of all the
operations performed against the database. It must also be possible to
find particular statements that are of interest to an auditor. The
standard logging facility shows what the user requested, while pgAudit
focuses on the details of what happened while the database was
satisfying the request.
For HIPAA compliance using PgAudit, should I log all or is there another value that makes sense
When it comes to HIPAA compliance, I do not have any experience in the topic, but in this page it is mentioned that part of the Technical safeguards of HIPAA security rule is to introduce activity logs and audit controls.
Maybe combining the IAM logs (Who did what, where, and when?) with the pgAudit(executed commands and queries) will provide better coverage to face this implementation specification.
How do I register a Pivotal Cloud Foundry Service Broker to make it accessible from multiple spaces within the same Organization, if I have Org-level permissions?
We tried to register a PCF Service broker (cf create-service-broker ...) in one space, then use it as a 'service instance' (cf create-service ...) in another space.
To illustrate the problem, consider the following work flow, from a HashiCorp Vault guide:
$ cf create-space examplespace
$ cf target -s examplespace
$ cf create-service-broker vault-broker "${AUTH_USERNAME}" "${AUTH_PASSWORD}" "https://${BROKER_URL}" --space-scoped
$ cf marketplace
service plans description
hashicorp-vault shared HashiCorp Vault Service Broker
# ...
$ cf create-service hashicorp-vault shared my-vault
The above works fine. The problem comes up when we have an app in a different space that we want to consume the HashiCorp Vault API:
$ cf target -s myappspace
$ cf bind-service my-app my-vault
This last part fails.
Also, now that I'm in the space myappspace, cf marketplace does **notCC show the new service broker.
Now, we have someone on our team with org-admin permissions.
I figured that we could just register the new service broker at the org level, using enable-service-access subcommand:
https://docs.cloudfoundry.org/services/access-control.html#enable-access-to-service-plans
$ cf enable-service-access my-vault -o WebOrg
This failed as well, because, even though he had Admin permissions for the entire org, he got a permission denied error.
If we then go on to registering the service broker in the second space, myappspace, we get a
All three of these methods failed, but there has to be some way to make a service from one space available to the others, within an Org., if I have administrative permissions for that PCF Org.
How?
A similar (although more specific) type of this issue is documented in the following two github issues for PCF's cloud_controller_ng repository:
https://github.com/cloudfoundry/cloud_controller_ng/issues/935
https://github.com/cloudfoundry/cloud_controller_ng/issues/837
I've done the following research:
https://docs.cloudfoundry.org/services/managing-service-brokers.html#register-broker
https://docs.cloudfoundry.org/services/access-control.html
https://docs.cloudfoundry.org/services/access-control.html#enable-access-to-service-plans
https://starkandwayne.com/blog/register-your-own-service-broker-with-any-cloud-foundry/
(We ran variations of every command on this page.)
The most similar of the existing questions on Stack Overflow were these:
WebSphere Message Broker - how to send a PCF message
Need help on Registering App on PCF with Spring Cloud Data Flow which is also on PCF
They don't seem to have much to do with name spacing issues in the PCF marketplace, or with PCF permissions management.
Note: At first I wanted to post this to serverfault.com, because this has more to do with the infrastructure for an application, rather than just programming. But, while serverfault.com has no tag for Pivotal Cloud Foundry, Stack Overflow has a pivotal-cloud-foundry tag with 588 uses, already.
How do I register a Pivotal Cloud Foundry Service Broker to make it accessible from multiple spaces within the same Organization, if I have Org-level permissions?
I don't think you can do this. You'd need to be a platform admin/operator. Then you'd need to register the service broker with the platform & mark that broker as accessible to select orgs & spaces. You could then create services instances & if the broker permits share them across spaces.
If you only have org/space permissions, you can only register the service broker with a specific space. It's then only visible in that space.
Without platform admin/operator permissions, I think the best you could do would be this:
register the broker in a specific space
create a service instance in that space
bind that to your apps in this space
create a service key for your app in the second space
switch to the second space
create a user provided service in that space and enter the service key info
Repeat steps 4-6 for each app in the second service (this ensure you get unique credentials per app, you could use one service key for all apps if you don't care about this).
Happy to be corrected, but I think that is the state of things as I write this.
Assuming you are using PCF 2.1 or above.
Service brokers must explicitly enable service instance sharing by setting a flag in their service-level metadata object. This allows service instances, of any service plan, to be shared across orgs and spaces.
This is from Enabling Service Instance Sharing
Looks like you have already followed the rest of steps from Sharing Service Intances
Is it possible to get access to events generated by User Account and Authentication (UAA) server in the context of Swisscom Application Cloud?
It is essential for me, to be able to have an audit trail of actions executed by authorised operators through the API (that would include cli and portal).
What I am looking for is an alternative of AWS CloudTrail for IAM module, that you can turn on for specific VPCs / regions there.
I have found this in the CF documentation (https://docs.cloudfoundry.org/loggregator/cc-uaa-logging.html) but that (as far as I understand it) requires infrastructure level access.
Thanks a lot for any hints.
We can't expose UAA logs to individual customers since it contains probably sensitive information about other users or the platform.
You should be able to retrieve the logs of your application in the application logs (which you can send to a syslog drain, i.e. the ELK/Elasticsearch service).
All API interactions should be covered by this log stream, according to the documentation:
Users make API calls to request changes in app state. Cloud Controller, the Cloud Foundry component responsible for the API, logs the actions that Cloud Controller takes in response.
For example:
2016-06-14T14:10:05.36-0700 [API/0] OUT Updated app with guid cdabc600-0b73-48e1-b7d2-26af2c63f933 ({"name"=>"spring-music", "instances"=>1, "memory"=>512, "environment_json"=>"PRIVATE DATA HIDDEN"})
From https://docs.cloudfoundry.org/devguide/deploy-apps/streaming-logs.html